* [RAUC] Regarding booting problem ,when booting manually @ 2018-10-18 5:16 Abhishek Kumar Rai 2018-10-18 5:29 ` Middelschulte, Leif 0 siblings, 1 reply; 7+ messages in thread From: Abhishek Kumar Rai @ 2018-10-18 5:16 UTC (permalink / raw) To: rauc [-- Attachment #1.1: Type: text/plain, Size: 2177 bytes --] Hi Team, I am facing one issue after doing following steps: 1. flashing any image in appfs. 2. rauc status mark-active rootfs.0.(Activated rootfs.0) 3. reboot *It is booting from rootfs.1,instead of rootfs.0 which has been marked active.* *It seems that rauc status mark-active rootfs.0 is having some issue ?* Please find system.conf content below {{{ $ cat /etc/rauc/system.conf [system] compatible=eximius bootloader=uboot mountprefix=/mnt/rauc statusfile=/factory/rauc.status [keyring] path=cert.pem [slot.rootfs.0] #device=/dev/mmcblk1p1 device=/dev/disk/by-path/platform-219c000.usdhc-part1 type=ext4 bootname=A [slot.rootfs.1] #device=/dev/mmcblk1p2 device=/dev/disk/by-path/platform-219c000.usdhc-part2 type=ext4 bootname=B [slot.appfs.0] #device=/dev/mmcblk1p5 device=/dev/disk/by-path/platform-219c000.usdhc-part5 type=ext4 bootname=app }}} Please provide your valuable input or suggestions on the above problem. Regards, Abhishek Rai -- The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you for your cooperation. -- _This e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. If you are not an intended recipient, please delete this message. Thank you. _ [-- Attachment #1.2: Type: text/html, Size: 2860 bytes --] [-- Attachment #2: Type: text/plain, Size: 65 bytes --] _______________________________________________ RAUC mailing list ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] Regarding booting problem ,when booting manually 2018-10-18 5:16 [RAUC] Regarding booting problem ,when booting manually Abhishek Kumar Rai @ 2018-10-18 5:29 ` Middelschulte, Leif 2018-10-18 5:57 ` Enrico Joerns 0 siblings, 1 reply; 7+ messages in thread From: Middelschulte, Leif @ 2018-10-18 5:29 UTC (permalink / raw) To: abhishekr, rauc Hello Abhishek, Am Donnerstag, den 18.10.2018, 10:46 +0530 schrieb Abhishek Kumar Rai: > Hi Team, > > I am facing one issue after doing following steps: > 1. flashing any image in appfs. > 2. rauc status mark-active rootfs.0.(Activated rootfs.0) Is this update considered successful by rauc? What do the logs say? If you're using systemd, you might want to check using `journalctl -u rauc`. > 3. reboot > It is booting from rootfs.1,instead of rootfs.0 which has been marked active. If your update was indeed succesful, your boot target's `remaining_attempts` (see [0]) are 0. > > It seems that rauc status mark-active rootfs.0 is having some issue ? Again, you might want to check rauc's logs on this. [0] https://www.barebox.org/doc/latest/user/bootchooser.html#the-bootchooser-algorithm BR, Leif > > Please find system.conf content below > {{{ > $ cat /etc/rauc/system.conf > [system] > compatible=eximius > bootloader=uboot > mountprefix=/mnt/rauc > statusfile=/factory/rauc.status > > [keyring] > path=cert.pem > > [slot.rootfs.0] > #device=/dev/mmcblk1p1 > device=/dev/disk/by-path/platform-219c000.usdhc-part1 > type=ext4 > bootname=A > > [slot.rootfs.1] > #device=/dev/mmcblk1p2 > device=/dev/disk/by-path/platform-219c000.usdhc-part2 > type=ext4 > bootname=B > > [slot.appfs.0] > #device=/dev/mmcblk1p5 > device=/dev/disk/by-path/platform-219c000.usdhc-part5 > type=ext4 > bootname=app > }}} > Please provide your valuable input or suggestions on the above problem. > > Regards, > Abhishek Rai > > > The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended > to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is > strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by > replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you for > your cooperation. > > This e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. If you are not an intended recipient, please > delete this message. Thank you. > _______________________________________________ > RAUC mailing list _______________________________________________ RAUC mailing list ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] Regarding booting problem ,when booting manually 2018-10-18 5:29 ` Middelschulte, Leif @ 2018-10-18 5:57 ` Enrico Joerns 2018-10-18 6:51 ` Abhishek Kumar Rai 0 siblings, 1 reply; 7+ messages in thread From: Enrico Joerns @ 2018-10-18 5:57 UTC (permalink / raw) To: abhishekr; +Cc: Middelschulte, Leif, rauc On 10/18/18 7:29 AM, Middelschulte, Leif wrote: > Hello Abhishek, > > Am Donnerstag, den 18.10.2018, 10:46 +0530 schrieb Abhishek Kumar Rai: >> Hi Team, >> >> I am facing one issue after doing following steps: >> 1. flashing any image in appfs. >> 2. rauc status mark-active rootfs.0.(Activated rootfs.0) > Is this update considered successful by rauc? What do the logs say? If you're using systemd, you might want to check using `journalctl -u rauc`. >> 3. reboot >> It is booting from rootfs.1,instead of rootfs.0 which has been marked active. > If your update was indeed succesful, your boot target's `remaining_attempts` (see [0]) are 0. I fear when using U-Boot he does not have the chance to use such a sophisticated boot selection framework as barebox has ;) But it would be worth making sure that the U-Boot scripts perform as expected. For debugging, one can also take a look at the raw output of fw_printenv in userspace before and after performing mark-good to see if the variables changed according to your expectation. It could also help verifying if the variables look the same in U-Boot as they do in userspace. >> It seems that rauc status mark-active rootfs.0 is having some issue ? > Again, you might want to check rauc's logs on this. Yes, should be really hard to say where the issue comes from with the current information. Another crucial information that we need: Which version of RAUC do you use? Regards, Enrico > [0] https://www.barebox.org/doc/latest/user/bootchooser.html#the-bootchooser-algorithm > > BR, > > Leif > >> >> Please find system.conf content below >> {{{ >> $ cat /etc/rauc/system.conf >> [system] >> compatible=eximius >> bootloader=uboot >> mountprefix=/mnt/rauc >> statusfile=/factory/rauc.status >> >> [keyring] >> path=cert.pem >> >> [slot.rootfs.0] >> #device=/dev/mmcblk1p1 >> device=/dev/disk/by-path/platform-219c000.usdhc-part1 >> type=ext4 >> bootname=A >> >> [slot.rootfs.1] >> #device=/dev/mmcblk1p2 >> device=/dev/disk/by-path/platform-219c000.usdhc-part2 >> type=ext4 >> bootname=B >> >> [slot.appfs.0] >> #device=/dev/mmcblk1p5 >> device=/dev/disk/by-path/platform-219c000.usdhc-part5 >> type=ext4 >> bootname=app >> }}} >> Please provide your valuable input or suggestions on the above problem. >> >> Regards, >> Abhishek Rai >> >> >> The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended >> to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is >> strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by >> replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you for >> your cooperation. >> >> This e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. If you are not an intended recipient, please >> delete this message. Thank you. >> _______________________________________________ >> RAUC mailing list > _______________________________________________ > RAUC mailing list > -- Pengutronix e.K. | Enrico Jörns | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ RAUC mailing list ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] Regarding booting problem ,when booting manually 2018-10-18 5:57 ` Enrico Joerns @ 2018-10-18 6:51 ` Abhishek Kumar Rai 2018-10-18 7:07 ` Abhishek Kumar Rai 2018-10-18 7:26 ` Enrico Joerns 0 siblings, 2 replies; 7+ messages in thread From: Abhishek Kumar Rai @ 2018-10-18 6:51 UTC (permalink / raw) To: ejo; +Cc: Leif.Middelschulte, rauc [-- Attachment #1.1: Type: text/plain, Size: 9087 bytes --] Hi Enrico & Leif, Thanks for your prompt reply. >> I am facing one issue after doing following steps: >> 1. flashing any image in appfs. >> 2. rauc status mark-active rootfs.0.(Activated rootfs.0) > Is this update considered successful by rauc? What do the logs say? If you're using systemd, you might want to check using `journalctl -u rauc`. >> 3. reboot >> It is booting from rootfs.1,instead of rootfs.0 which has been marked active. > If your update was indeed succesful, your boot target's `remaining_attempts` (see [0]) are 0. >>I fear when using U-Boot he does not have the chance to use such a sophisticated boot selection framework as barebox has ;) I agree >>But it would be worth making sure that the U-Boot scripts perform as expected. >>For debugging, one can also take a look at the raw output of fw_printenv in userspace >>before and after performing mark-good to see if the variables changed according to your expectation. It could also help verifying if the variables look the same in U-Boot as they do in userspace. Please find output of command after doing $ rauc status mark-active rootfs.0 {{{ $ fw_printenv bootcmd=for b in ${bootcmd_list} ; do echo Running ${b} ; run ${b}; done bootdelay=3 baudrate=115200 ethprime=FEC loadaddr=0x12000000 scriptaddr=0x11000000 fdt_addr=0x18000000 loadaddr=0x12000000 console=ttymxc0 baudrate=115200 fdt_high=0xffffffff initrd_high=0xffffffff bootcmd_list=usb_bootcmd net_bootcmd mmc_bootcmd usb_dev=0 usb_part=1 usb_script=usb_boot.scr usb_load=usb start && usb dev && load usb ${usb_dev}:${usb_part} ${scriptaddr} boot/${usb_script} usb_bootcmd=run usb_load && source ${scriptaddr} mmc_script=mmc_boot.scr mmc_dev=0 mmc_part=1 mmc_load=load mmc ${mmc_dev}:${mmc_part} ${scriptaddr} boot/${mmc_script} mmc_bootcmd=run mmc_load && source ${scriptaddr} net_script=net_boot.scr ipaddr=192.168.168.2 serverip=192.168.168.20 nfsroot=/srv/nfs/tkmac net_load=nfs ${scriptaddr} ${nfsroot}/boot/${net_script} net_bootcmd=run net_load && source ${scriptaddr} panel=TRULY-WVGA video_args_hdmi=setenv video_args $video_args video=mxcfb${fb}:dev=hdmi,1280x720M@60,if=RGB24 video_args_lvds=setenv video_args $video_args video=mxcfb${fb}:dev=ldb,LDB-XGA,if=RGB666 video_args_lcd=setenv video_args $video_args video=mxcfb${fb}:dev=lcd,TRULY-WVGA,if=RGB24,rotate=3 video_interfaces=lcd fb=0 video_args_script=for v in ${video_interfaces}; do run video_args_${v}; setexpr fb $fb + 1; done BOOT_B_LEFT=3 BOOT_app_LEFT=3 BOOT_A_LEFT=3 BOOT_ORDER=A app B }}} >> It seems that rauc status mark-active rootfs.0 is having some issue ? > Again, you might want to check rauc's logs on this. I have checked rauc logs rootfs.0 is marked active. {{{ root@eximius:~# journalctl -u rauc -- Logs begin at Tue 2018-06-19 17:41:28 UTC, end at Tue 2018-06-19 17:49:47 UTC. -- Jun 19 17:41:32 eximius systemd[1]: Starting Rauc Update Service... Jun 19 17:41:32 eximius rauc[290]: Cannot open /dev/disk/by-path/platform-219c000.usdhc: No such file or directory Jun 19 17:41:32 eximius rauc[290]: Error: environment not initialized Jun 19 17:41:32 eximius rauc[290]: rauc mark: Failed marking 'rootfs.1' as good: Failed to run fw_setenv: Child process exited with code 1 Jun 19 17:41:32 eximius systemd[1]: Started Rauc Update Service. Jun 19 17:49:47 eximius rauc[290]: rauc mark: activated slot rootfs.0 }}} >>Yes, should be really hard to say where the issue comes from with the current information. >>Another crucial information that we need: Which version of RAUC do you use? {{{ $rauc --version rauc 0.4 }}} Regards, Abhishek Rai On Thu, Oct 18, 2018 at 11:27 AM Enrico Joerns <ejo@pengutronix.de> wrote: > On 10/18/18 7:29 AM, Middelschulte, Leif wrote: > > Hello Abhishek, > > > > Am Donnerstag, den 18.10.2018, 10:46 +0530 schrieb Abhishek Kumar Rai: > >> Hi Team, > >> > >> I am facing one issue after doing following steps: > >> 1. flashing any image in appfs. > >> 2. rauc status mark-active rootfs.0.(Activated rootfs.0) > > Is this update considered successful by rauc? What do the logs say? If > you're using systemd, you might want to check using `journalctl -u rauc`. > >> 3. reboot > >> It is booting from rootfs.1,instead of rootfs.0 which has been marked > active. > > If your update was indeed succesful, your boot target's > `remaining_attempts` (see [0]) are 0. > > I fear when using U-Boot he does not have the chance to use such a > sophisticated boot selection framework as barebox has ;) > > But it would be worth making sure that the U-Boot scripts perform as > expected. > > For debugging, one can also take a look at the raw output of fw_printenv > in userspace > before and after performing mark-good to see if the variables changed > according to your expectation. > > It could also help verifying if the variables look the same in U-Boot as > they do in userspace. > > >> It seems that rauc status mark-active rootfs.0 is having some issue ? > > Again, you might want to check rauc's logs on this. > > Yes, should be really hard to say where the issue comes from with the > current information. > Another crucial information that we need: Which version of RAUC do you use? > > > Regards, Enrico > > > [0] > https://www.barebox.org/doc/latest/user/bootchooser.html#the-bootchooser-algorithm > > > > BR, > > > > Leif > > > >> > >> Please find system.conf content below > >> {{{ > >> $ cat /etc/rauc/system.conf > >> [system] > >> compatible=eximius > >> bootloader=uboot > >> mountprefix=/mnt/rauc > >> statusfile=/factory/rauc.status > >> > >> [keyring] > >> path=cert.pem > >> > >> [slot.rootfs.0] > >> #device=/dev/mmcblk1p1 > >> device=/dev/disk/by-path/platform-219c000.usdhc-part1 > >> type=ext4 > >> bootname=A > >> > >> [slot.rootfs.1] > >> #device=/dev/mmcblk1p2 > >> device=/dev/disk/by-path/platform-219c000.usdhc-part2 > >> type=ext4 > >> bootname=B > >> > >> [slot.appfs.0] > >> #device=/dev/mmcblk1p5 > >> device=/dev/disk/by-path/platform-219c000.usdhc-part5 > >> type=ext4 > >> bootname=app > >> }}} > >> Please provide your valuable input or suggestions on the above problem. > >> > >> Regards, > >> Abhishek Rai > >> > >> > >> The information contained in this e-mail message (including any > attachments) may be confidential, proprietary, privileged, or otherwise > exempt from disclosure under applicable laws. It is intended > >> to be conveyed only to the designated recipient(s). Any use, > dissemination, distribution, printing, retaining or copying of this e-mail > (including its attachments) by unintended recipient(s) is > >> strictly prohibited and may be unlawful. If you are not an intended > recipient of this e-mail, or believe that you have received this e-mail in > error, please notify the sender immediately (by > >> replying to this e-mail), delete any and all copies of this e-mail > (including any attachments) from your system, and do not disclose the > content of this e-mail to any other person. Thank you for > >> your cooperation. > >> > >> This e-mail message (including any attachments) may be confidential, > proprietary, privileged, or otherwise exempt from disclosure under > applicable laws. If you are not an intended recipient, please > >> delete this message. Thank you. > >> _______________________________________________ > >> RAUC mailing list > > _______________________________________________ > > RAUC mailing list > > > > -- > Pengutronix e.K. | Enrico Jörns | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > > -- The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you for your cooperation. -- _This e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. If you are not an intended recipient, please delete this message. Thank you. _ [-- Attachment #1.2: Type: text/html, Size: 11995 bytes --] [-- Attachment #2: Type: text/plain, Size: 65 bytes --] _______________________________________________ RAUC mailing list ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] Regarding booting problem ,when booting manually 2018-10-18 6:51 ` Abhishek Kumar Rai @ 2018-10-18 7:07 ` Abhishek Kumar Rai 2018-10-18 7:28 ` Enrico Joerns 2018-10-18 7:26 ` Enrico Joerns 1 sibling, 1 reply; 7+ messages in thread From: Abhishek Kumar Rai @ 2018-10-18 7:07 UTC (permalink / raw) To: ejo; +Cc: Leif.Middelschulte, rauc [-- Attachment #1.1: Type: text/plain, Size: 9830 bytes --] Hi team, One more point that i missed adding. I am using BSP provided by our vendor and in that reboot and shutdown option are not gracefully exiting. They are giving kernel panic. There is only option to do power reset. could this have any impact on rauc behavior ? Regards, Abhishek Rai On Thu, Oct 18, 2018 at 12:21 PM Abhishek Kumar Rai < abhishekr@eximiusdesign.com> wrote: > Hi Enrico & Leif, > > Thanks for your prompt reply. > >> I am facing one issue after doing following steps: > >> 1. flashing any image in appfs. > >> 2. rauc status mark-active rootfs.0.(Activated rootfs.0) > > Is this update considered successful by rauc? What do the logs say? If > you're using systemd, you might want to check using `journalctl -u rauc`. > >> 3. reboot > >> It is booting from rootfs.1,instead of rootfs.0 which has been marked > active. > > If your update was indeed succesful, your boot target's > `remaining_attempts` (see [0]) are 0. > > >>I fear when using U-Boot he does not have the chance to use such a > sophisticated boot selection framework as barebox has ;) > I agree > > > >>But it would be worth making sure that the U-Boot scripts perform as > expected. > > >>For debugging, one can also take a look at the raw output of fw_printenv > in userspace > >>before and after performing mark-good to see if the variables changed > according to your expectation. > > It could also help verifying if the variables look the same in U-Boot as > they do in userspace. > Please find output of command after doing $ rauc status mark-active > rootfs.0 > {{{ > $ > fw_printenv > > bootcmd=for b in ${bootcmd_list} ; do echo Running ${b} ; run ${b}; done > bootdelay=3 > baudrate=115200 > ethprime=FEC > loadaddr=0x12000000 > scriptaddr=0x11000000 > fdt_addr=0x18000000 > loadaddr=0x12000000 > console=ttymxc0 > baudrate=115200 > fdt_high=0xffffffff > initrd_high=0xffffffff > bootcmd_list=usb_bootcmd net_bootcmd mmc_bootcmd > usb_dev=0 > usb_part=1 > usb_script=usb_boot.scr > usb_load=usb start && usb dev && load usb ${usb_dev}:${usb_part} > ${scriptaddr} boot/${usb_script} > usb_bootcmd=run usb_load && source ${scriptaddr} > mmc_script=mmc_boot.scr > mmc_dev=0 > mmc_part=1 > mmc_load=load mmc ${mmc_dev}:${mmc_part} ${scriptaddr} boot/${mmc_script} > mmc_bootcmd=run mmc_load && source ${scriptaddr} > net_script=net_boot.scr > ipaddr=192.168.168.2 > serverip=192.168.168.20 > nfsroot=/srv/nfs/tkmac > net_load=nfs ${scriptaddr} ${nfsroot}/boot/${net_script} > net_bootcmd=run net_load && source ${scriptaddr} > panel=TRULY-WVGA > video_args_hdmi=setenv video_args $video_args > video=mxcfb${fb}:dev=hdmi,1280x720M@60,if=RGB24 > video_args_lvds=setenv video_args $video_args > video=mxcfb${fb}:dev=ldb,LDB-XGA,if=RGB666 > video_args_lcd=setenv video_args $video_args > video=mxcfb${fb}:dev=lcd,TRULY-WVGA,if=RGB24,rotate=3 > video_interfaces=lcd > fb=0 > video_args_script=for v in ${video_interfaces}; do run video_args_${v}; > setexpr fb $fb + 1; done > BOOT_B_LEFT=3 > BOOT_app_LEFT=3 > BOOT_A_LEFT=3 > BOOT_ORDER=A app B > }}} > > > >> It seems that rauc status mark-active rootfs.0 is having some issue ? > > Again, you might want to check rauc's logs on this. > I have checked rauc logs rootfs.0 is marked active. > {{{ > root@eximius:~# journalctl -u > rauc > > -- Logs begin at Tue 2018-06-19 17:41:28 UTC, end at Tue 2018-06-19 > 17:49:47 UTC. -- > Jun 19 17:41:32 eximius systemd[1]: Starting Rauc Update Service... > Jun 19 17:41:32 eximius rauc[290]: Cannot open > /dev/disk/by-path/platform-219c000.usdhc: No such file or directory > Jun 19 17:41:32 eximius rauc[290]: Error: environment not initialized > Jun 19 17:41:32 eximius rauc[290]: rauc mark: Failed marking 'rootfs.1' as > good: Failed to run fw_setenv: Child process exited with code 1 > Jun 19 17:41:32 eximius systemd[1]: Started Rauc Update Service. > Jun 19 17:49:47 eximius rauc[290]: rauc mark: activated slot rootfs.0 > }}} > > > >>Yes, should be really hard to say where the issue comes from with the > current information. > >>Another crucial information that we need: Which version of RAUC do you > use? > {{{ > $rauc --version > rauc 0.4 > }}} > > Regards, > Abhishek Rai > > On Thu, Oct 18, 2018 at 11:27 AM Enrico Joerns <ejo@pengutronix.de> wrote: > >> On 10/18/18 7:29 AM, Middelschulte, Leif wrote: >> > Hello Abhishek, >> > >> > Am Donnerstag, den 18.10.2018, 10:46 +0530 schrieb Abhishek Kumar Rai: >> >> Hi Team, >> >> >> >> I am facing one issue after doing following steps: >> >> 1. flashing any image in appfs. >> >> 2. rauc status mark-active rootfs.0.(Activated rootfs.0) >> > Is this update considered successful by rauc? What do the logs say? If >> you're using systemd, you might want to check using `journalctl -u rauc`. >> >> 3. reboot >> >> It is booting from rootfs.1,instead of rootfs.0 which has been marked >> active. >> > If your update was indeed succesful, your boot target's >> `remaining_attempts` (see [0]) are 0. >> >> I fear when using U-Boot he does not have the chance to use such a >> sophisticated boot selection framework as barebox has ;) >> >> But it would be worth making sure that the U-Boot scripts perform as >> expected. >> >> For debugging, one can also take a look at the raw output of fw_printenv >> in userspace >> before and after performing mark-good to see if the variables changed >> according to your expectation. >> >> It could also help verifying if the variables look the same in U-Boot as >> they do in userspace. >> >> >> It seems that rauc status mark-active rootfs.0 is having some issue ? >> > Again, you might want to check rauc's logs on this. >> >> Yes, should be really hard to say where the issue comes from with the >> current information. >> Another crucial information that we need: Which version of RAUC do you >> use? >> >> >> Regards, Enrico >> >> > [0] >> https://www.barebox.org/doc/latest/user/bootchooser.html#the-bootchooser-algorithm >> > >> > BR, >> > >> > Leif >> > >> >> >> >> Please find system.conf content below >> >> {{{ >> >> $ cat /etc/rauc/system.conf >> >> [system] >> >> compatible=eximius >> >> bootloader=uboot >> >> mountprefix=/mnt/rauc >> >> statusfile=/factory/rauc.status >> >> >> >> [keyring] >> >> path=cert.pem >> >> >> >> [slot.rootfs.0] >> >> #device=/dev/mmcblk1p1 >> >> device=/dev/disk/by-path/platform-219c000.usdhc-part1 >> >> type=ext4 >> >> bootname=A >> >> >> >> [slot.rootfs.1] >> >> #device=/dev/mmcblk1p2 >> >> device=/dev/disk/by-path/platform-219c000.usdhc-part2 >> >> type=ext4 >> >> bootname=B >> >> >> >> [slot.appfs.0] >> >> #device=/dev/mmcblk1p5 >> >> device=/dev/disk/by-path/platform-219c000.usdhc-part5 >> >> type=ext4 >> >> bootname=app >> >> }}} >> >> Please provide your valuable input or suggestions on the above problem. >> >> >> >> Regards, >> >> Abhishek Rai >> >> >> >> >> >> The information contained in this e-mail message (including any >> attachments) may be confidential, proprietary, privileged, or otherwise >> exempt from disclosure under applicable laws. It is intended >> >> to be conveyed only to the designated recipient(s). Any use, >> dissemination, distribution, printing, retaining or copying of this e-mail >> (including its attachments) by unintended recipient(s) is >> >> strictly prohibited and may be unlawful. If you are not an intended >> recipient of this e-mail, or believe that you have received this e-mail in >> error, please notify the sender immediately (by >> >> replying to this e-mail), delete any and all copies of this e-mail >> (including any attachments) from your system, and do not disclose the >> content of this e-mail to any other person. Thank you for >> >> your cooperation. >> >> >> >> This e-mail message (including any attachments) may be confidential, >> proprietary, privileged, or otherwise exempt from disclosure under >> applicable laws. If you are not an intended recipient, please >> >> delete this message. Thank you. >> >> _______________________________________________ >> >> RAUC mailing list >> > _______________________________________________ >> > RAUC mailing list >> > >> >> -- >> Pengutronix e.K. | Enrico Jörns | >> Industrial Linux Solutions | http://www.pengutronix.de/ >> | >> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | >> >> -- The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you for your cooperation. -- _This e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. If you are not an intended recipient, please delete this message. Thank you. _ [-- Attachment #1.2: Type: text/html, Size: 13065 bytes --] [-- Attachment #2: Type: text/plain, Size: 65 bytes --] _______________________________________________ RAUC mailing list ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] Regarding booting problem ,when booting manually 2018-10-18 7:07 ` Abhishek Kumar Rai @ 2018-10-18 7:28 ` Enrico Joerns 0 siblings, 0 replies; 7+ messages in thread From: Enrico Joerns @ 2018-10-18 7:28 UTC (permalink / raw) To: Abhishek Kumar Rai; +Cc: Leif.Middelschulte, rauc On 10/18/18 9:07 AM, Abhishek Kumar Rai wrote: > Hi team, > > One more point that i missed adding. > I am using BSP provided by our vendor and in that reboot and shutdown option are not gracefully exiting. > They are giving kernel panic. There is only option to do power reset. > > could this have any impact on rauc behavior ? No, it shouldn't. Everything will be persisted at the end of RAUC's install run. Regards, Enrico -- Pengutronix e.K. | Enrico Jörns | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ RAUC mailing list ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RAUC] Regarding booting problem ,when booting manually 2018-10-18 6:51 ` Abhishek Kumar Rai 2018-10-18 7:07 ` Abhishek Kumar Rai @ 2018-10-18 7:26 ` Enrico Joerns 1 sibling, 0 replies; 7+ messages in thread From: Enrico Joerns @ 2018-10-18 7:26 UTC (permalink / raw) To: Abhishek Kumar Rai; +Cc: Leif.Middelschulte, rauc Hi Abhishek, On 10/18/18 8:51 AM, Abhishek Kumar Rai wrote: > >>For debugging, one can also take a look at the raw output of fw_printenv in userspace > >>before and after performing mark-good to see if the variables changed according to your expectation. > > > It could also help verifying if the variables look the same in U-Boot as they do in userspace. > Please find output of command after doing $ rauc status mark-active rootfs.0 > {{{ > $ fw_printenv > bootcmd=for b in ${bootcmd_list} ; do echo Running ${b} ; run ${b}; done > bootdelay=3 > baudrate=115200 > ethprime=FEC > loadaddr=0x12000000 > scriptaddr=0x11000000 > fdt_addr=0x18000000 > loadaddr=0x12000000 > console=ttymxc0 > baudrate=115200 > fdt_high=0xffffffff > initrd_high=0xffffffff > bootcmd_list=usb_bootcmd net_bootcmd mmc_bootcmd > usb_dev=0 > usb_part=1 > usb_script=usb_boot.scr > usb_load=usb start && usb dev && load usb ${usb_dev}:${usb_part} ${scriptaddr} boot/${usb_script} > usb_bootcmd=run usb_load && source ${scriptaddr} > mmc_script=mmc_boot.scr > mmc_dev=0 > mmc_part=1 > mmc_load=load mmc ${mmc_dev}:${mmc_part} ${scriptaddr} boot/${mmc_script} > mmc_bootcmd=run mmc_load && source ${scriptaddr} > net_script=net_boot.scr > ipaddr=192.168.168.2 > serverip=192.168.168.20 > nfsroot=/srv/nfs/tkmac > net_load=nfs ${scriptaddr} ${nfsroot}/boot/${net_script} > net_bootcmd=run net_load && source ${scriptaddr} > panel=TRULY-WVGA > video_args_hdmi=setenv video_args $video_args video=mxcfb${fb}:dev=hdmi,1280x720M@60,if=RGB24 > video_args_lvds=setenv video_args $video_args video=mxcfb${fb}:dev=ldb,LDB-XGA,if=RGB666 > video_args_lcd=setenv video_args $video_args video=mxcfb${fb}:dev=lcd,TRULY-WVGA,if=RGB24,rotate=3 > video_interfaces=lcd > fb=0 > video_args_script=for v in ${video_interfaces}; do run video_args_${v}; setexpr fb $fb + 1; done > BOOT_B_LEFT=3 > BOOT_app_LEFT=3 > BOOT_A_LEFT=3 > BOOT_ORDER=A app B > }}} mark-active on rootfs.0 should result in A being the first entry in BOOT_ORDER. This is true here, however, we do not know if this was true before and simply remained unchanged. A before / after comparison would be something like fw_printenv | grep BOOT rauc status mark-active rootfs.1 fw_printenv | grep BOOT >>> It seems that rauc status mark-active rootfs.0 is having some issue ? >> Again, you might want to check rauc's logs on this. > I have checked rauc logs rootfs.0 is marked active. > {{{ > root@eximius:~# journalctl -u rauc > -- Logs begin at Tue 2018-06-19 17:41:28 UTC, end at Tue 2018-06-19 17:49:47 UTC. -- > Jun 19 17:41:32 eximius systemd[1]: Starting Rauc Update Service... > Jun 19 17:41:32 eximius rauc[290]: Cannot open /dev/disk/by-path/platform-219c000.usdhc: No such file or directory > Jun 19 17:41:32 eximius rauc[290]: Error: environment not initialized > Jun 19 17:41:32 eximius rauc[290]: rauc mark: Failed marking 'rootfs.1' as good: Failed to run fw_setenv: Child process exited with code 1 This seems to have failed! Which is consistent with what you described from your observation. Thus the question is not if env is wrong or something like this, the question is why fw_setenv fails. Threads on Github targeting a similar issue are https://github.com/rauc/rauc/issues/165 or https://github.com/rauc/rauc/issues/173 Maybe you run into this, too? This resulted in documentation update https://github.com/rauc/rauc/pull/174/commits/cff3a61509230d662e6bd1a44a6ee8d7e4d9eb58. > Jun 19 17:41:32 eximius systemd[1]: Started Rauc Update Service. > Jun 19 17:49:47 eximius rauc[290]: rauc mark: activated slot rootfs.0 > }}} > >>Yes, should be really hard to say where the issue comes from with the current information. > >>Another crucial information that we need: Which version of RAUC do you use? > {{{ > $rauc --version > rauc 0.4 > }}} Ok. When already using (GitHub) markdown syntax here it seems worth posting this to GitHub instead of mailing list? ;) Best Regards Enrico -- Pengutronix e.K. | Enrico Jörns | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ RAUC mailing list ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-10-18 7:28 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-18 5:16 [RAUC] Regarding booting problem ,when booting manually Abhishek Kumar Rai 2018-10-18 5:29 ` Middelschulte, Leif 2018-10-18 5:57 ` Enrico Joerns 2018-10-18 6:51 ` Abhishek Kumar Rai 2018-10-18 7:07 ` Abhishek Kumar Rai 2018-10-18 7:28 ` Enrico Joerns 2018-10-18 7:26 ` Enrico Joerns
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox