| Thread Previous • Date Previous • Date Next • Thread Next |
Hi Nio, I may have found the issue!!! Since it ONLY happens in mkpxpy I lookedthis is the issue (in bold) please change it in your live version and test it. I will be uploading and rebuilding this. (BTW what is suidblkid stored in a variable for??)
suidblkid=$(blkid -c /dev/null|grep "$swappart"|grep 'TYPE="swap"') * retval=$?** ** export suidblkid* if (( retval != 0 )) then LOGecho "$Useexistingswappartition $swappart - $keepitsUUID" swapoff "$swappart" else LOGecho "$Makeaswappartition $swappart - $andgetnewUUID" mkswap "$swappart" fiswapuid=$(grep ^UUID "${CHROOT}/etc/fstab"|grep swap|sed -e s/\ .*// -e 's/UUID=//') RELEASE=$(chroot "${CHROOT}" bash -c "lsb_release -a | grep Codename:| sed 's/.*\t//'")
if [[ "${RELEASE}" == "precise" ]]
then
swapUUID=$(blkid "$swappart"|sed -e 's/.*UUID="//' -e 's/".*//')
else
swapUUID=$(blkid "$swappart"|sed -e 's/.* UUID="//' -e 's/".*//')
fi
The issue, is the old SWAP UUID issue, but the problem was intermittent
because the return value was based on export suidblkid :)
so most of the time it would make a new one and (from your log) [mkp] Make a swap partition /dev/sda2 - and *get new UUID* So I think the delay was because of this Swap snafuI am almost certain this is the issue. I went through and commented confirm-partition heavily as well as mkpxpy until I discovered the issue.
On 05/04/2016 07:14 AM, Nio Wiklund wrote:
Hi Israel,I continued testing by installing Lubuntu Xenial 32 bit, released as 16.04 LTS. I installed Xenial into partition #7 (and shared the swap on partition #2.It works. Booting the other distros via Xenial's grub menu:Booting ToriOS on partition #1 is still affected by the 1 min 30 s delay, but it works.The test a couple of days ago showed that this is not a problem (with Yakkety, but it is still almost the same as Xenial) if ToriOS has *not* tampered with the drive at the advanced level.Booting ToriOS on partition #6 was fast (no delay). It was not tampered with as a previously installed system by ToriOS.Best regards Nio Den 2016-05-04 kl. 13:43, skrev Nio Wiklund:Hi again, Here are the log files. Best regards Nio Den 2016-05-04 kl. 09:39, skrev Nio Wiklund:Hi Israel, Installing into an HDD connected internally via SATA. I wiped the first megabyte of the drive and made a fresh MSDOS partition table. 1. ToriOS-debian-daily.iso - installed at the basic OBI level obi-installer-basic.log /mnt was not mounted 2. Booted into the installed system It works. Ran sudo update-grub. It boots as it should (no delay). 3. Installed another system. Since you might be suspicious about Yakkety, I selected Lubuntu 14.04.1 LTS (with the trusty kernel). I partitioned the HDD with several partitions for future use. I installed Lubuntu (32-bit) to partition #5 (sharing swap with ToriOS on partition #2). 4. Booted into the installed Lubuntu system. It works (and it had found ToriOS for grub). 5. Booted into ToriOS (in partition #1) It boots as it should. It works. Ran sudo update-grub. 6. Booted into both now installed systems. - Lubuntu boots as it should (not delayed with 1 min 30 s). - ToriOS boots as it should (not delayed with 1 min 30 s). So far this result is the same as with an external target drive. 7. ToriOS-debian-daily.iso - installed at the advanced OBI level into partition #6 (sharing swap on partition #2). obi-installer-advanced.log /mnt was not mounted 8. Booted into (the new) ToriOS at partition #6. It had found the previously installed systems (ToriOS and Lubuntu) for grub. It boots as it should (not delayed with 1 min 30 s). 9. Booted into the old ToriOS at partition #1. It boots, but is delayed with 1 min 30 s.10. Booted into Lubuntu at partition #5. (I made a cold boot in order towipe any possible cruft from RAM. It booted faster (not delayed with 1 min 30 s). But this version of Lubuntu boots with init, not systemd. I think the Ubuntu flavours use systemd from Wily (so also Xenial and Yakkety). And ToriOS-debian uses systemd. 11. I tried again with ToriOS. - It booted fast into the newer system (in partition #6) as before. - It booted slowly into the older system (in partition #1) as before. *. I noticed, when I booted without quiet splash, that there was a complaint about a failure: failed to start LSB, apparmor initialization and a suggestion to use systemctl to check it. Maybe it is a clue to the problem. I have not tried (yet) with the tweaks that you suggested. Best regards Nio Den 2016-05-04 kl. 03:35, skrev Israel:Nio, If you want to try installing grub from the OBI in the other fashion sed -i "s/grub-installer/grubfix/g" /usr/share/OBI/mkp This is the regular grub installer script #!/bin/bash dest="/dev/sda" if [ "$1" != "" ] then dest="$1" fi grub-install "${dest}" update-grub && echo "updated grub" There is no progress or logging, but it may work. AFAIK updating grub will not do much for the /mnt OS though. This is why we moved to the chroot method (the recommended method to recover grub from a live OS in many many wikis for all the distros I have looked at) I think the big issue is that something is calling dbus, but I do not know what. On 05/03/2016 02:42 PM, Nio Wiklund wrote:Hi Israel, [inline] Best regards Nio Den 2016-05-03 kl. 21:21, skrev Israel:Hi Nio, (inlines) On 05/03/2016 07:28 AM, Nio Wiklund wrote:Hi Israel, [inline] Best regards Nio Den 2016-05-03 kl. 01:51, skrev Israel:... hmmm... can I have the log please?I'm sorry, but I think they are long gone. I have rebooted several times.It should be there even when you reboot! The newer version has a date in the name of the log. I thought this would be nice to have in the log title.I will check, what I can find.Probably the only task that really might need chroot is installingthebootloader, and that task might not cause this damage. Now you have the same [grub] system in the live session and the tarball, so youprobably you do not even need chroot for that task. I don't use chroot in my original One Button Installer, but it was introduced in 9w, where I run a Debian system to install from Ubuntu tarballs.No. the entire user configuration happens in the chroot (setting the language/timezone/username/password/installing pae etc...) Those do not seem to have effected everything poorly.But, my killing of dbus might. please send the log, this will makethings more clear.I don't understand what you are using dbus for, and how you are usingit. Or is it activated automatically by the Debian Jessie system?I am not sure what starts dbus either. It may be started by one of theinstall processes. I assumed it was because the menus were updated...It may be due to something else.......yes, you tested installing ToriOS on 2 partitions and Yakkety Yak (don't talk back :D) on a 3rd. This is probably not common. But I think the log file will be very helpful to me finding the issueI don't think it makes much difference what previous operating systemthere are. Maybe it makes a greater difference if it is an internal drive or a USB drive. I can try that (and save the log files), probably later today.So do you mean that the time you installed on external it made everything slow in booting? Please clarify this a bit more.It is confusing for me (too). I cannot clarify yet, but I suspect thatthere is something fishy going on when you run things with chroot. I tested with the target drive connected via USB 3. I had an HDD and after that an SSD in the akasa external box. The problems affected both drives. I will test with the target drive connected internally via SATA. I don't know yet, if it will make any difference concerning slowness (the 1 min 30 s delay). I know it makes a difference concerning the grub menu: It seems that sudo update-grub finds previous operatingsystems in the internal drive (but not in a drive connected via USB 3.I could test in another computer too, but this one (the Toshiba) is the fastest, so the most convenient for testing. And it works well with Lubuntu and the other official Ubuntu flavours as well as with Debian Jessie.
-- Regards
| Thread Previous • Date Previous • Date Next • Thread Next |
