Den 2016-05-06 kl. 14:49, skrev Nio Wiklund:
Den 2016-05-06 kl. 14:39, skrev Israel:
On 05/06/2016 07:32 AM, Nio Wiklund wrote:
Den 2016-05-05 kl. 22:27, skrev Israel:
Hi all,
I have done some testing with the most recent ISO.
There is an issue.
If I resize a partition and add a new partition, then try to reuse the
original swap, the original OS does not find the swap.
This has the long boot bug.
The solution?
perhaps the only real solution is to manually generate fstab files for
EVERY install that exists, assuming that they are on the same device
(if
it is repartitioned) I do not think this issue existed previous to
systemd inclusion, but systemd does something to verify the UUID of
the
drives, and this causes issues in our instance.
So unfortunately there is more testing to be done....
Hi Israel,
[Replying again]
I have not yet done the testing, but I have tried to understand.
Are you saying that ToriOS debian does not accept to 're-use' the swap
partition's UUID, hence making it hard to share a swap partition with
a previously installed system?
I am not sure [yet] that it should be blamed on systemd, because
Xenial and Yakkety are not affected and they boot via systemd. Maybe
it is a feature of Debian, that it creates/refreshes the swap
partition. In that case you can try to store the UUID in a shell
variable uidsav and reuse it with
mkswap -U $uidsav $swaptarget
instead of having to rewrite all the fstab files.
(Maybe this is what you have already done ?!)
Best regards
Nio
No, it may be that when I resized the device it changed things.
my swap was on the same drive and I added a partition between the swap
and original device. so it was
/dev/sda1 torios (19 gig)
/dev/sda2 [SWAP]
and became
/dev/sda1 torios (4 Gig)
/dev/sda3 new obi root (15 gig)
/dev/sda5 [SWAP] shared swap
Does this make sense?
It makes sense, but it is not what I was doing, and I was affected by
the problem. I have checked, and it is correct, that the UUID of the
swap partition was changed (I think by ToriOS debian OBI-installer at
the advanced level).
I still think
mkswap -U $uidsav $swaptarget
after the installer has tampered with it might be a solution.
Best regards
Nio
Hi Israel,
This time I have tested your brand new ToriOS-Debian-daily.iso file :-)
I did it in my Toshiba to an SSD connected via USB 3, the 'tough' testcase.
1. Installed ToriOS at the basic OBI level using the whole drive, to
/dev/sda1 with swap at /dev/sda2.
The installation worked and the installed system works.
2. Installed a small text based Trusty from Trusty-mini-txt7.tar.xz
using my original One Button Installer
to /dev/sda5 with swap at /dev/sda2.
The installation worked and the installed system works. Also the
previous system at /dev/sda1 works, no delay, swap active.
3. Installed Lubuntu Yakkety from the Lubuntu i386 iso file to
to /dev/sda6 with swap at /dev/sda2.
It uses systemd. It works, and does not damage the previous systems at
/dev/sda1 and /dev/sda5.
4. Installed ToriOS at the advanced OBI level to
to /dev/sda7 with swap at /dev/sda2.
It works, but damages the previous systems because it changed the UUID
of the swap partition /dev/sda2. And the previous systems are not
modified (fstab still points to the old UUID).
5. See the obi-installer log files and the saved output of
sudo lsblk -fm
a. lsblk-fm_sda1_repeated shows how the situation evolves after each new
system is installed. You can notice that the UUID has changed by the
installation at the advanced OBI level.
b. lsblk-fm_live-advanced shows that the installer uses this swap
partition while it is still working, and with a new UUID !!!
You get a summary with the following command
grep sda2 lsblk-fm_*|sed s/4\.7G.*// > summary-by-grep
In the OBI-installer it should be possible to swapoff and after that
change back the UUID of the swap partition to what it was before. That
would make the previously installed systems happy.
If the live system grabs the swap and changes its UUID before the
OBI-installer is started, it will be trickier.
Maybe it would be possible to prevent using swap in the live system
until you have saved the original UUID of the target swap partition to a
shell variable or a file, maybe using 'crontab -e @reboot'. It runs
before the desktop environment is started. After saving you could let it
use swap, since that would make things work better in low-RAM computers.
Best regards
Nio
