Installing BunsenLabs Helium-dev

jimjamz · 2017-08-11 13:54:09

Would it be possible to follow these steps for Buster (currently in testing) and incorporate BL on top of that?

Sector11 · 2017-08-11 15:08:40

Just a thought here that boils down to another way of doing it.

Rather than "moving" or "renaming" $HOME, why not copy it to a USB stick, a data partition or as I do; to an EXT HDD (with rsync). Then reinstall allowing the install to do ~/ as well, and then copy ~/.mozilla, ~/.thunderbird and other other stuff you want over from the copied ~/ ?

In fact I keep the "data bases" for thunderbird and claws-mail on a separate partition as well.

so for example: /home/sector11/.thunderbird/profiles.ini looks like this

[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=0
Path=/media/5/Thunderbird/{some-coded-stuff}.default

That way dual or triple booting, with those using /media/5, and everything is accessible from any installed system with only one "database" that is backed up regularly. I've been doing this since #! Statler » Waldorf » BL.

Should do that with ~/.mozilla as well, then it's just copying a few files vs the whole database for each install.

And the profile.ini file on /media/5 match the profile.ini file in ~/ so I have that as a backup as well.

Head_on_a_Stick · 2017-08-11 16:06:26

jimjamz wrote:

Would it be possible to follow these steps for Buster (currently in testing) and incorporate BL on top of that?

Only if you like broken systems.

But seriously, Debian testing is *not* intended for day-to-day use — the only people who should be using that branch are those interesting in finding problems and bugs for Debian and in that context installing BL on top makes little sense.

DeepDayze · 2017-08-12 00:03:55

Head_on_a_Stick wrote:

jimjamz wrote:
Would it be possible to follow these steps for Buster (currently in testing) and incorporate BL on top of that?
Only if you like broken systems.
But seriously, Debian testing is *not* intended for day-to-day use — the only people who should be using that branch are those interesting in finding problems and bugs for Debian and in that context installing BL on top makes little sense.

You can also say the same for Sid, as updates can occur every few hours. Sid is for those who live on the edge as things can and will break easily.

KrunchTime · 2017-08-12 00:06:29

DeepDayze wrote:

You can also say the same for Sid, as updates can occur every few hours. Sid is for those who live on the edge as things can and will break easily.

But Testing can stay broken longer since it takes longer for packages to migrate from Unstable (Sid) to Testing than it does for packages to migrate from Experimental to Unstable.

Don't mean to hijack the thread, but I use Unstable to be able to use newer packages and see what new things are being done.

Last edited by KrunchTime (2017-08-12 00:08:01)

DeepDayze · 2017-08-12 00:07:37

KrunchTime wrote:

DeepDayze wrote:
You can also say the same for Sid, as updates can occur every few hours. Sid is for those who live on the edge as things can and will break easily.
But Testing can stay broken longer since it takes longer for packages to migrate from Unstable (Sid) to Testing than it does for packages to migrate from Experimental to Unstable.

Yes that's true and now I can see why Testing is more "unstable" than Sid aka Unstable.

Head_on_a_Stick · 2017-08-12 11:05:33

The confusion arises because Debian use the term "stable" to refer to the rate of change of package versions and in that respect it is certainly true that testing is more stable than sid because the packages get updated less frequently.

Unfortunately, most people seem to (incorrectly) infer that "stable" is a synonym for "reliable" and it is probably not the case that testing is more reliable than sid (in my limited experience anyway).

jimjamz · 2017-08-14 17:03:24

I prefer to follow the forums better judgment, so staying with Stretch/Stable seems best. I didn't really that that Buster/testing would be in such a dire state, but you guys know better than I, and I do need a daily system.

Probably not the correct place to ask, but when is it likely that we will have a general BL release built upon Stretch?

damo · 2017-08-14 17:27:31

it isn't that it is in a "dire state", but that you need to take care, know how to selectively hold packages, monitor bug reports, and be prepared to fix breakages!

Helium release date...Topics Going Nowhere

KrunchTime · 2017-08-14 22:05:39

jimjamz wrote:

...and I do need a daily system.

You can have both. Ever heard of dual or multi boot? Or, you could run testing or unstable in a VM if you have the specs to do so.

KrunchTime · 2017-08-19 22:27:37

Head_on_a_Stick wrote:

If a conventional ISO image is used for installation then I would recommend disabling the bootloader step in the installer and updating the pre-existing bootloader configuration afterwards instead.

Why?

johnraff · 2017-08-20 04:53:42

Hi HoaS I finally followed your chroot method to install helium-dev on a separate partition on this machine. It worked perfectly - many thanks!

Two small points:
1) You might indicate how to cleanly exit the chroot after the netinstall script has finished. I did 'exit' (or Ctrl+d) twice (once to leave the user a/c, once to leave the chroot), then

for i in /proc /sys /dev/pts /dev; do umount /mnt$i; done
umount /mnt

I guess that's enough?

2) Although the netinstall script (now) installs lvm2, other users on lvm setups might like to be reminded to install it before trying to boot the new system.

Head_on_a_Stick · 2017-08-20 10:42:15

KrunchTime wrote:

Head_on_a_Stick wrote:
If a conventional ISO image is used for installation then I would recommend disabling the bootloader step in the installer and updating the pre-existing bootloader configuration afterwards instead.
Why?

Because Helium-dev is still in development so in a multiboot environment it would seem to make more sense to use the main (ie, pre-existing) system to control the bootloader.

Using Helium-dev to control GRUB should also work, if you want to do that instead.

Head_on_a_Stick · 2017-08-20 10:46:07

johnraff wrote:

You might indicate how to cleanly exit the chroot after the netinstall script has finished. I did 'exit' (or Ctrl+d) twice (once to leave the user a/c, once to leave the chroot), then
for i in /proc /sys /dev/pts /dev; do umount /mnt$i; done
umount /mnt
I guess that's enough?

Actually I never bother umounting /mnt, I just let systemd tidy up my mess in the reboot

If it bothered you though just the single command would be enough to "clean" the tree:

sudo umount -R /mnt

johnraff wrote:

Although the netinstall script (now) installs lvm2, other users on lvm setups might like to be reminded to install it before trying to boot the new system.

Are all the necessary packages for LVM not installed?

That sounds like a bug to me (I've never touched LVM).

KrunchTime · 2017-08-20 22:00:49

Head_on_a_Stick wrote:

KrunchTime wrote:
Head_on_a_Stick wrote:
If a conventional ISO image is used for installation then I would recommend disabling the bootloader step in the installer and updating the pre-existing bootloader configuration afterwards instead.
Why?
Because Helium-dev is still in development so in a multiboot environment it would seem to make more sense to use the main (ie, pre-existing) system to control the bootloader.
Using Helium-dev to control GRUB should also work, if you want to do that instead.

I guess I'm still a bit confused. Right now, there is no ISO for Helium, so Helium-dev is just a script to bring in the BL goodies. I always run BL stable and BL tracking Unstable in a dual-boot setup, with BL stable always controlling the bootloader (grub?). IOW, I never setup grub as a bootloader in my BL-Unstable install. When I go to install Stretch via netinstall, I'll install grub as the bootloader, overwriting the existing setup from BL-Hydrogen.

johnraff · 2017-08-21 03:41:58

Head_on_a_Stick wrote:

johnraff wrote:
You might indicate how to cleanly exit the chroot after the netinstall script has finished. I did 'exit' (or Ctrl+d) twice (once to leave the user a/c, once to leave the chroot), then
for i in /proc /sys /dev/pts /dev; do umount /mnt$i; done
umount /mnt
I guess that's enough?
Actually I never bother umounting /mnt, I just let systemd tidy up my mess in the reboot

But I didn't want to go straight to a reboot. I wanted to stay in the host system, to do this:

HoaS wrote:

Bootloader
Remember to run `sudo update-grub` (from the "host") after finishing the entire installation, this should pick up the new system and provide a menu entry in the GRUB bootloader.

If it bothered you though just the single command would be enough to "clean" the tree:
sudo umount -R /mnt

Ah, another man I should have read. Yes, the -R option covers it - thanks!

johnraff wrote:
Although the netinstall script (now) installs lvm2, other users on lvm setups might like to be reminded to install it before trying to boot the new system.
Are all the necessary packages for LVM not installed?
That sounds like a bug to me (I've never touched LVM).

Installed where, by what? Of course they're all in the host system (put in by debian-installer right at the start), but without installing lvm2 in the new chroot-installed system then grub was unable to find its partition. In the shell it dropped down to, 'blkid' just showed the container partition. Seems reasonable enough.

Head_on_a_Stick · 2017-08-21 20:36:43

I have changed /etc/apt/sources.list from http to https due to overwhelming public demand. *

Anybody who has already installed Helium-dev should run:

sudo apt install apt-transport-https

Then either edit /etc/apt/sources.list manually (with `sudo apt edit-sources`) or use:

sudo sed -i 's/http/https/' /etc/apt/sources.list

Remember to update the package database afterwards:

sudo apt update

* 8o

KrunchTime · 2017-08-22 00:03:24

^ You should also add that info to your OP. What you've posted here will get buried.

johnraff · 2017-08-22 02:58:03

^, ^^ & ^^^
Please

Head_on_a_Stick · 2017-08-22 06:36:30

KrunchTime wrote:

You should also add that info to your OP. What you've posted here will get buried.

I have changed the instructions in the OP so they use https, anybody who has already installed will be much more likely to notice my bump than an addition to the OP (which will be utterly pointless for everybody else) — why would they go back and read through the guide again if the system is already installed?

#81 2017-08-11 13:54:09

Re: Installing BunsenLabs Helium-dev

#82 2017-08-11 15:08:40

Re: Installing BunsenLabs Helium-dev

#83 2017-08-11 16:06:26

Re: Installing BunsenLabs Helium-dev

#84 2017-08-12 00:03:55

Re: Installing BunsenLabs Helium-dev

#85 2017-08-12 00:06:29

Re: Installing BunsenLabs Helium-dev

#86 2017-08-12 00:07:37

Re: Installing BunsenLabs Helium-dev

#87 2017-08-12 11:05:33

Re: Installing BunsenLabs Helium-dev

#88 2017-08-14 17:03:24

Re: Installing BunsenLabs Helium-dev

#89 2017-08-14 17:27:31

Re: Installing BunsenLabs Helium-dev

#90 2017-08-14 22:05:39

Re: Installing BunsenLabs Helium-dev

#91 2017-08-19 22:27:37

Re: Installing BunsenLabs Helium-dev

#92 2017-08-20 04:53:42

Re: Installing BunsenLabs Helium-dev

#93 2017-08-20 10:42:15

Re: Installing BunsenLabs Helium-dev

#94 2017-08-20 10:46:07

Re: Installing BunsenLabs Helium-dev

#95 2017-08-20 22:00:49

Re: Installing BunsenLabs Helium-dev

#96 2017-08-21 03:41:58

Re: Installing BunsenLabs Helium-dev

#97 2017-08-21 20:36:43

Re: Installing BunsenLabs Helium-dev

#98 2017-08-22 00:03:24

Re: Installing BunsenLabs Helium-dev

#99 2017-08-22 02:58:03

Re: Installing BunsenLabs Helium-dev

#100 2017-08-22 06:36:30

Re: Installing BunsenLabs Helium-dev

Board footer