| Thread Previous • Date Previous • Date Next • Thread Next |
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 to wipe 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 installing the bootloader, and that task might not cause this damage. Now you have the same [grub] system in the live session and the tarball, so you probably 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 make things more clear.I don't understand what you are using dbus for, and how you are using it. 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 the install 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 system there 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 that there 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 operating systems 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.
| Thread Previous • Date Previous • Date Next • Thread Next |
