STATUS: IDLE BUILD: 1.8.2: c9f0a99050ec0050f0dbcd55d0cd2ab18848113f ENVIRONMENT: genericx86 - on MMAX32bit STEPS TO REPRODUCE: 1. plugin usb which contains live image burned 2. configure device BIOS to firstly boot from USB if necessary 3. boot the device and select option "Install" from boot menu 4. proceed through default install process 5. Remove USB, and reboot into new installed system. EXPECTED OUTCOME: 1. User can choose install system from usb stick onto harddisk from boot menu or command line option 2. Installed system can boot up ACTUAL OUTCOME: 1. The image should be installed successfully in the new media item. The next error message is displayed: "(sdc): Volume was not properly unmounted. Some data may be corrupt. Please run fsck."
Hi Francisco, Just a question for error message on "sdc", do you have another storage (e.g USB drive or SD card) on your board?
(In reply to comment #1) > Hi Francisco, > Just a question for error message on "sdc", do you have another storage (e.g > USB drive or SD card) on your board? Hi, Yes I had another storage media connected to the minnow board max.
Thanks log for your quick confirmation. Could you test again without any other removable media (just usb installer drive and internal storage on MMax board)?
(In reply to comment #3) > Thanks log for your quick confirmation. Could you test again without any > other removable media (just usb installer drive and internal storage on MMax > board)? Hi sorry for the delay for minnowboard max, I do not have HDD external, I always install from USB to USB or from SD Card to USB. I need to get an external storage device.
Francisco, Could you help to confirm that the installation procedure caused this warning message? I am thinking it could also be from any other force ejections not related to installation. I suggest to verify it with these steps: () Fix any disk mount warnings to make this message disappear. You probably need to power off device from software instead of cutting power. () Boot twice board with image from command line, you shouldn't see this error message if disk has been fixed. Otherwise, we could have same problem for boot too. () Boot and install image to the board, when installation is finished, follow the prompt to remove disk and reboot device. () Check if the message shows up. I think by doing so we can know exactly if installation caused the issue. I will try the same thing on my NUC since I saw similar log but can't remember if the original disk status is okay or not. (Sometimes I just force shutdown device without proper shutdown procedure.
Test results about procedure in description and commentary 5, this procedure was done in four different versions meta-intel, 1.8.2, 2.0.2 and current (master) using SD card as installation device, the links are bellow meta-intel 5.0: http://yocto-ab-master.ostc.intel.com/pub/releases/yocto-meta-intel-5.0-krogoth-2.1.rc3/machines/intel-core2-32/core-image-sato-sdk-ptest-intel-core2-32.hddimg 1.8.2: Link lost but the image is: core-image-sato-sdk-genericx86.hddimg 2.0.2 http://autobuilder.yoctoproject.org/pub/releases/yocto-2.0.2/machines/genericx86/core-image-sato-sdk-genericx86.hddimg Current 32 bits: http://autobuilder.yoctoproject.org/pub/releases/CURRENT/machines/genericx86/core-image-sato-sdk-genericx86.hddimg Current 64 bits: http://autobuilder.yoctoproject.org/pub/releases/CURRENT/machines/genericx86-64/core-image-sato-sdk-genericx86-64.hddimg We found that all of them with exception of meta-intel, the system does not install using SD card, same message displayed: "... sd: 0:0:0:0 [sda] attached SCSI removable disk Searching for hard drives ... No hard drive selected. Installation aborted. Installation image failed. sh: can't acces tty job control turned off." Meta-intel 5.0 was the only one installed and booted correctly with any problems. About the message "FAT-fs (sda): volume was not properly unmounted. Some data mat be corrupt. Please run fsck." meta-intel 5.0 installed correctly no message displayed no message displayed booting from USB live image 1.8.2 installation aborted no message displayed till the installation break 2.0.2 installation aborted no message displayed till the installation break message displayed booting from USB live image Current (master) installation aborted no message displayed till the installation break message displayed booting from USB live image also, tests were done in different minnow-board MAX bios versions, 0.90 and 0.92 obtaining the same results. Regards David Rodriguez
David, Thanks for the detailed cross-test and I am caching up from other tasks back to this issue. () "1.8.2 installation aborted no message displayed till the installation break" This sounds strange if you tested against same commit tip c9f0a9905 for 1.8.2 in original bug description. Francisco didn't mention unsuccessful installation and actually he saw the concerned warning message of sdc device. Are you sure you tested an image built from same commit tip and hardware? Comment 5 by me is to figure out if the sdc was already in a bad status before, or our installation procedure really caused it. () It looks you are addressing different issue(s) among different distro images and releases. I suggest you to have other tickets to track them. If you can confirm the original warning message is gone with procedure in comment 5 after any drive connected is fixed by fsck tool and installation is okay, I would conclude this warning message is caused by a previous wrong status of drive and close it. Thanks
Indeed, I think they are different issues. The links of specific releases in which I worked with are specified above and are correct, 1.8.2 image was obtain from our back up files, cross-test was suggested by Saul Wold. I tested again with Francisco board, same results obtained. The fact that USB-SDcard installation was not possible involves that the procedure in comment 5 was incomplete for 3 releases (1.8.2, 2.0.2 and current), except for meta-intel. I couldn’t confirm if the message was display or not on the installed system on those releases. The SD card was clean at the beginning of each test (formatted as FAT32), same card is used in all tests. Also, I don’t know if the messages are related with the fact that the system didn’t install correctly or not, but, booting from the USB live image, the dmesg message : "(sdc): Volume was not properly unmounted. Some data may be corrupt. Please run fsck." is displayed in all of them except for meta-intel 5.0. I’ll track this on next release and a new ticket will be open if needed.
Created attachment 3250 [details] cant acces tty This was found on 2.2 M1, poky : 6f0c5537e02c59e1c8f3b08f598dc049ff8ee098 STATUS: FAILED genericx86 - on MMAX32bit installing from USB live image to external SD-drive drive the image: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2_M1.rc2/genericx86/core-image-sato-sdk-genericx86.hddimg RESULT:Installation process not completed, panic message is diplayed, see attached file. An external sata drive via USB is used for installation. An extended cross-release analysis comment 6 and comment 8 on bug 9652 can be found.
Just a side note. Would using partition uuids instead of device names resolve this? I've implemented similar thing for oe installer year ago: http://lists.openembedded.org/pipermail/openembedded-core/2015-June/106093.html Would it make sense for me to try to implement it for sdk installer as well?
Ed, The current EFI installer is using UUID to specify rootfs. And I think it was from your work (78bacee0) in OE. For the original warning message "...sdc...", I found an easier way to reproduce it. Live-booting USB stick on device then using "reboot" command to reboot it, the warning will show in the next reboot. However, if I install the image to device and then reboot it same way, this warning message never shows. I suspect something causes unmount of live-boot drive failed before reboot. Using UUID has some downsides but it is another story. Thanks lot!
I don't see a failure of installation or live-boot so far. Just some more investigation with below procedure: () dd image to usb stick () live-boot device with this usb stick () dmesg|grep fsck () You should NOT see the warning message "(sdx): Volume was not properly unmounted...fsck..." because this is the first boot and FS is clean. () reboot device properly from command line (I use "reboot") () after reboot, run "dmesg|grep fsck" Now the USB stick causes the warning message. That means its FS is dirty. I suspect this could be due to the mounting in boot procedure. We mount USB live boot stick and then also mount rootfs.img on it as rootfs. System possibly cannot unmount them before reboot and leaves FS in a dirty mode. The original issue happens only with USB stick that boots the system. Installed image on device doesn't have the issue. If I mount another USB stick and change the content on it, then just reboot system without unmount, the issue doesn't appear either. It means that kernel normally automatically unmount file systems prior to reboot. It could be tricky to fix this issue.
https://github.com/torvalds/linux/commit/b88a105802e9aeb6e234e8106659f5d1271081bb Reference for how kernel handle dirty flag for FAT FS.
This is a wrap-up of what I digged out to draw a temporary conclusion of this bug. This bug can be easily reproduced with a FS clean live-boot usb stick. This fsck warning message will show up since the 2nd boot cycle because FS is left dirty from the first reboot. () b88a105802e9aeb6e234e8106659f5d1271081bb in kernel explains how kernel handle dirty bit of FAT filesystem. Notice it won't set dirty bit when FS is clean and mounted as RO. () The current OE live-boot and install-efi init scripts mount USB live-boot media as RW for the convenience of developers' daily work, based on a discussion in IRC. These scripts will mount a file rootfs.img as the real root / as a loop device from RW mounted live-boot FAT FS, so I think kernel is unable to unmount live-boot media and clean dirty bit before a reboot as it can usually due to this nested mounting design. I think it is appropriate to mount live-boot media and rootfs image as read-only (RO) in _any_ cases as a normal feature. What developers enjoy should be regarded as a useful debug option. But changing to RO causes more changes and potential breakages in different pieces in OE. Actually, some previous attempts were reverted out when people ran into issues with similar patches. Maybe we should whitelist this warning message now until a re-design or an agreement on only using direct-boot (wic) image for a writable rootfs, which is more justified in my opinion, is in sight.
Hi Francisco, After a discussion with Saul, we suggest whitelist this error message and close this bug as "won't fix" based on my warp-up at comment #14. Could you help to do the whitelist in OE stack and then close it? Or feel free to let me know any other thoughts for this bug. Thanks
(In reply to comment #15) > Hi Francisco, > After a discussion with Saul, we suggest whitelist this error message and > close this bug as "won't fix" based on my warp-up at comment #14. > > Could you help to do the whitelist in OE stack and then close it? Or feel > free to let me know any other thoughts for this bug. > > Thanks Hi about this, I just tested http://autobuilder.yoctoproject.org/pub/nightly/20160819-1/machines/genericx86-64-lsb/ and the image was unable to install, blocking the some execution for compliance testing. I would like to have this one not closed.
A new bug was opened to track the issue of the installation bug 10189. Regarding to the message talked on this bug can be white listed, as this is a manual test we need to add a note directly to the test case.
Jose, are you taking care of updating this in the manual test case?
(In reply to comment #18) > Jose, are you taking care of updating this in the manual test case? Test case was already updated with the needed info, setting the bug as resolved https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=196