← Back to team overview

torios-dev team mailing list archive

Re: new problem - it is extremely slow booting older instances of ToriOS

 

Hi Nio,
so the slow boot is ONLY at advanced level?
Ok this clears it up more for me.
I will look into what is different in those two. I might make a base that the two (confirm-partition and select-device do differently and the functions they source, etc.. I will need to comment the OBI code heavily at some point soon to make things clear for you and I as well as others in the future.

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 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
issue

I 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.







--
Regards



References