Cloning Devuan to a different partition updating linux-krnl initrd-img

fungus · 2017-07-15 11:34:52

As mentioned elsewhere in my installation experience when I cloned the original usb installation to a different partition (dev/sda11) with a new uuid grub although updated and found the clone it had mixed uuid instructions based on the initrd-image found in the boot menu, and kept looking for the old uuid to boot which was not plugged.

Interestingly if the original installation was plugged in (let's say /dev/sdb1), although the grub menu would have two other lines defining sda11 as a specific/correct id it would eventually boot from sdb1.

Correcting grub to match the properly edited fstab for root booted, but it seemed slow and confused.

I am running ascii. I added ceres repositories and only installed linux-4.11 from which I am booted now.

I removed 3.16 and reinstalled 4.9

By the way, with ascii and booting 4.11 I have yet to experience anything strange, it works like a charm.

During the removal and reinstallation I got this:

(Reading database ... 147327 files and directories currently installed.)
Purging configuration files for linux-image-3.16.0-4-amd64 (3.16.43-2+deb8u2) ...
debconf: unable to initialize frontend: Gnome
debconf: (Can't locate Gtk2.pm in @INC (you may need to install the Gtk2 module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Debconf/FrontEnd/Gnome.pm line 91.)
debconf: falling back to frontend: Dialog
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline

This may be due to the inconsistency of running ceres kernel in ascii, I will now reboot and revert the kernel to 4.9 and remove 4.11
I will report back on how it went!

fungus · 2017-07-15 12:25:05

The only glitch which may be related to the lxde desktop not really being a devuan ported pkg, was rsyslog which in ascii it says it has unmet non-existent dependencies. So I removed it.

Everything else is running fine.

Hopefully this information may help someone else cloning their devuan installation. I do this often when I want to play either with unstable or compile software that may break the system as a testing installation and only apply procedures that work on my main installation.
In this case I reversed the process leaving the original installation as the playground.

Let's see what ceres does (I am really going to miss SID as I liked the name - I will rename my grub entry Devuan SID or Vicious Devuan)

So long, systemd suckers!

miroR · 2017-07-15 13:11:35

fungus wrote:

As mentioned elsewhere in my installation experience when I cloned the original usb installation to a different partition (dev/sda11) with a new uuid grub

Just why not give the link, and at this very spot, so users who want, may visit the link?

although updated and found the clone it had mixed uuid instructions based on the initrd-image found in the boot menu, and kept looking for the old uuid to boot which was not plugged.
Interestingly if the original installation was plugged in (let's say /dev/sdb1), although the grub menu would have two other lines defining sda11 as a specific/correct id it would eventually boot from sdb1.
Correcting grub to match the properly edited fstab for root booted, but it seemed slow and confused.

I clone in cycles, from Air-Gapped which sees no internet, other than minuscule fragments that I only need to update it, and mail, and other stuff from online, but nothing wholesale.

And I run into the need to change UUIDs on my encrypted partitions all the time... But it works, not just slowly, here.

I am running ascii. I added ceres repositories and only installed linux-4.11 from which I am booted now.

I removed 3.16 and reinstalled 4.9

By the way, with ascii and booting 4.11 I have yet to experience anything strange, it works like a charm.

During the removal and reinstallation I got this:

(Reading database ... 147327 files and directories currently installed.)
Purging configuration files for linux-image-3.16.0-4-amd64 (3.16.43-2+deb8u2) ...
debconf: unable to initialize frontend: Gnome
debconf: (Can't locate Gtk2.pm in @INC (you may need to install the Gtk2 module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Debconf/FrontEnd/Gnome.pm line 91.)
debconf: falling back to frontend: Dialog
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline

Hmmmh, not related to UUIDs, don't know what this could be...

This may be due to the inconsistency of running ceres kernel in ascii, I will now reboot and revert the kernel to 4.9 and remove 4.11
I will report back on how it went!

I don't think... But I don't know.

miroR · 2017-07-15 13:16:43

fungus wrote:

The only glitch which may be related to the lxde desktop not really being a devuan ported pkg, was rsyslog which in ascii it says it has unmet non-existent dependencies. So I removed it.

And what do you have for system logging?

BTW, it's this bug:
rsyslog depends on liblognorm2 in ascii, but it's not available
https://bugs.devuan.org//cgi/bugreport.cgi?bug=96

I have rsyslog held back, because of that. But I don't have any issues with it. I think it can wait.

So what do you have for system logging, now that you removed rsyslog, the default system logger in Devuan(/Debian)?

Last edited by miroR (2017-07-15 13:19:26)

golinux · 2017-07-15 14:56:09

rsyslog is a known problem. Just throwing this here but please search the forum and DNG for other discussions.

https://botbot.me/freenode/devuan/2017- … 009&page=6

Bottom line:

fsmithred wrote:

rsyslog is not ready. Use syslog-ng or busybox-syslogd instead

fungus · 2017-07-15 15:22:28

I don't what is a bigger problem, not having logs or not been able to stop them. The new non-bug with systemd is that in some occassions it created a log to start a service and to stop it, creating a ton per minute of useless logging.
Thank you @golinux for the recommended alternatives.

@miroR you asked me for a link and I have no idea what link this may be. What I am talking about in reference to cloning is to make an installation in partition sdz1 and making a copy in partition sdy3 and debelop from the same snaposhot of the system 2 different ways.
All you need to do is to "properly" edit fstab with new uuids and the grub.cfg

I suspect, without knowing, that the initrd.img in /boot contains the original uuid which is passed to grub and it creates this confusion.
Once linux kernel gets updated all this goes away. In other words unattended updates of grub creates an entry with two different uuids for the same menu item, which results to a prompt at the initrdmfs prompt where there is not much you can do (or maybe there is if you know how to deal with it).

miroR · 2017-07-15 15:56:51

golinux wrote:

rsyslog is a known problem. Just throwing this here but please search the forum and DNG for other discussions.
https://botbot.me/freenode/devuan/2017- … 009&page=6
Bottom line:
fsmithred wrote:
rsyslog is not ready. Use syslog-ng or busybox-syslogd instead

I prefer waiting for rsyslog to get fixed. I have to say, it simply continues to work fine in my system(s).
See:

# lsb_release -a
No LSB modules are available.
Distributor ID: Devuan
Description:    Devuan GNU/Linux 2.0 (ascii)
Release:        2.0
Codename:       ascii
#

and:

# apt-cache policy rsyslog
rsyslog:
  Installed: 8.4.2-1+deb8u2
  Candidate: 8.14.0-2+devuan1.0
  Version table:
     8.23.0-2~bpo8+1 100
        100 http://auto.mirror.devuan.org/merged jessie-backports/main amd64 Package
     8.14.0-2+devuan1.0 500
        500 http://packages.devuan.org/merged ascii/main amd64 Packages
        500 http://auto.mirror.devuan.org/merged ascii/main amd64 Packages
        500 http://packages.devuan.org/devuan ascii/main amd64 Packages
 *** 8.4.2-1+deb8u2 100
        100 /var/lib/dpkg/status
#

but:

# apt-get install rsyslog
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) rsyslog:amd64 < 8.4.2-1+deb8u2 -> 8.14.0-2+devuan1.0 @ii pumU Ib >
Broken rsyslog:amd64 Depends on liblognorm2:amd64 < none @un H > (>= 1.1.2)
Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 rsyslog : Depends: liblognorm2 (>= 1.1.2) but it is not installable
E: Unable to correct problems, you have held broken packages.
#

Let readers see in full the inability to update to newer version... But, I repeat, I have no issues. It logs just great... (well... except for logging too much under grsec kernel, or my manually compiled grsec kernel... such as in all: kern.log, messages and syslog ... But I couldn't live without a lot of logging... It's such great tool to learn your system! Especially the configurably very abundant grsec kernel logging...)

fungus wrote:

I don't what is a bigger problem, not having logs or not been able to stop them.

You gotta have logs, c'mon!

The new non-bug with systemd is that in some occassions it created a log to start a service and to stop it, creating a ton per minute of useless logging.
Thank you @golinux for the recommended alternatives.
@miroR you asked me for a link and I have no idea what link this may be.

You just go into your profile, and open up your topics or your posts, and paste the link. But freely forget it, I was more like thoughtful for other readers and being principled (if I use the word correctly).

What I am talking about in reference to cloning is to make an installation in partition sdz1 and making a copy in partition sdy3 and debelop

debelop? a typo? develop you must have meant...

from the same snaposhot of the system 2 different ways.
All you need to do is to "properly" edit fstab with new uuids and the grub.cfg
I suspect, without knowing, that the initrd.img in /boot contains the original uuid which is passed to grub and it creates this confusion.
Once linux kernel gets updated all this goes away.

IOW, it's a mess because of the same UUIDs, and once you change them and run:

# update-initramfs -u -a

or somesuch, and if all UUIDs are set correctly, i.e. update-initramfs runs without errors, it then can, upon reboot, boot fine.

In other words unattended updates of grub creates an entry with two different uuids for the same menu item, which results to a prompt at the initrdmfs prompt where there is not much you can do (or maybe there is if you know how to deal with it).

initrdmfs? initramfs, yes...
Aaahh.. Great. Enjoy Devuan. I do!... Let's make this kind beast more and more capable and powerfull... Each giving the little or the much that any of us can...

Last edited by miroR (2017-07-15 16:04:04)

fungus · 2017-07-15 16:08:47

http://dev1galaxy.org/viewtopic.php?id=771

This where my installation troubles were listed as I found the topic relevant.

I am worried about somesuch, it always gets me.

IOW, it's a mess because of the same UUIDs, and once you change them and run:
# update-initramfs -u -a
or somesuch, and if all UUIDs are set correctly, i.e. update-initramfs runs without errors, it then can, upon reboot, boot fine.

fungus · 2017-07-15 16:15:57

# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
I: The initramfs will attempt to resume from /dev/sda9
I: (UUID=8e052cee-0f67-4af6-guud-707b91db2d1b)
I: Set the RESUME variable to override this.
live-boot: core filesystems devices utils udev wget blockdev dns.

dev/sda9 is the swap partition .... I remember seeing this during shutdown...?
Is it sweeping the swap? 4 different systems share the same swap space and the
same home partition. Not a problem ever. Since I have all 4 users being 1000
they all have access to each other's stuff. I did try a single same name 1001 user
but I like the variety of 4 users. Like this is my purple/violet personality ...!!

Last edited by fungus (2017-07-15 16:16:51)

miroR · 2017-07-15 17:57:27

fungus wrote:

# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
I: The initramfs will attempt to resume from /dev/sda9
I: (UUID=8e052cee-0f67-4af6-guud-707b91db2d1b)
I: Set the RESUME variable to override this.
live-boot: core filesystems devices utils udev wget blockdev dns.

dev/sda9 is the swap partition .... I remember seeing this during shutdown...?
Is it sweeping the swap?

If you use swap for resuming, you can't share it with other systems. That's all to it. But how to set it up, not fresh at it... Haven't used resume lately.

4 different systems share the same swap space and the
same home partition. Not a problem ever. Since I have all 4 users being 1000
they all have access to each other's stuff. I did try a single same name 1001 user
but I like the variety of 4 users. Like this is my purple/violet personality ...!!

Purple/violet is fine. Devuan is a purple beast... Well, to me. Or it's more like purpy, but one would have to ask the chief Devuan web/logo/other-stuff designer, one golinux for details .

EDIT 2017-07-18 21:18 UT START: You read in the next post:

fungus wrote:

I like this, the "admin" is hijacking my topic

That's because two posts from here to the post with that quote, belatedly (but that's fine, everyone gets tired in sleepy hours), moved to:
Devuan is a purpy beast
http://dev1galaxy.org/viewtopic.php?id=1147
Only noticed now, didn't get any notice about it (but Dev1Galaxy is fine enough).
EDIT 2017-07-18 21:18 UT END.

Last edited by miroR (2017-07-18 21:25:01)

fungus · 2017-07-16 07:59:13

I like this, the "admin" is hijacking my topic

On my testbed installation I jumped to ceres and linux4.11 which comes with header files that are not dependencies and did not exist in 3.16 or (maybe?) 4.9.

Slim was still installed before I switched to my trusty lightdm, but the login screen changed. Great background.jpg (look in share --> slim ). I kept it since lightdm is black bkgrnd. Definetely slim has a very slim footprint. The problem was there was no option to select anything other than entering user and password, so the xfce started.

Glancing through the menu the dreaded "services" was on, clicked and it was there. I got a cold chill down my spine, I thought the systemd nightmare was back! Quickly I checked through the tasks and I suppose those "services" are daemons started by the init system.
Phheeeewwww!!!!!!

fsmithred · 2017-07-16 10:35:17

If you have more than one window manager or desktop environment, the slim login screen will let you scroll through them with the F1 key.

rsyslog from jessie-backports installs and works in ascii, so that's another option. I haven't tried it in ceres.

To each, his own. I couldn't get away from the default slim background fast enough. Is it the blue one or the red one?

fungus · 2017-07-16 16:21:41

fsmithred wrote:

To each, his own. I couldn't get away from the default slim background fast enough. Is it the blue one or the red one?

That orangy looking mesh that came with ceres upgrade. It saus Text.4 somewhere on it

fungus · 2017-07-16 16:29:52

golinux wrote:

rsyslog is a known problem. Just throwing this here but please search the forum and DNG for other discussions.
https://botbot.me/freenode/devuan/2017- … 009&page=6
Bottom line:
fsmithred wrote:
rsyslog is not ready. Use syslog-ng or busybox-syslogd instead

syslog-ng seems to work fine, thank you for the heads-up

fungus · 2017-07-16 20:21:22

WOW!!!!

I am puzzled that nobody mentioned refractasnapshot. What an amazing tool!
I wish I had tried it before I went through all this trouble as described above.
I suppose the next stage would be to make a gui out of manually editing the two .conf files while browsing files/folders to exclude and
clicking on boxes for the options.

I had spend some time studying and practicing building live images and there was always something little I'd forget to do right and then the next time I had to figure it all out from scratch, as my note taking abilities are very poor.

This is making backups of the system a breeze. A good reason to be here alone.
One thing that didn't work was altering the directories for work and snapshot, they were still gone to the default locations. No problem.
The other was the part in the conf about processor use, I left it at 50 as was the default, but it went way up there at their limits and temps
went up as well. This went on while it was squashing the file system into the tiny image. I did run a tasks monitor in bg with low priority even
though it is not advised to run anything. I suspect that such process that run as standalones don't matter.

The refracta team deserves an aplaud! I was also told by someone in the xorisso team that they weren't aware of anyone working on a xorisso related gui. I guess this is not specifically a gui of xorisso but it seems that it is the next best thing.

Not happy, extatic of the possibilities this creates for some of us uncomfortable with code and sequences of commands.

fsmithred · 2017-07-16 23:13:03

Thanks for the appreciation. Glad it works for you.

You have to change limit_cpu="no" to "yes" for cpulimit to work. It's not on by default.

Changing the work and snapshot directories should work correctly. Check the config file to make sure you edited it correctly. Make sure the storage device is mounted. If you want a more verbose error log, run it in debug mode (add -d option or change the setting in the config file).

The officially official Devuan Forum!

#1 2017-07-15 11:34:52

Cloning Devuan to a different partition updating linux-krnl initrd-img

#2 2017-07-15 12:25:05

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#3 2017-07-15 13:11:35

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#4 2017-07-15 13:16:43

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#5 2017-07-15 14:56:09

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#6 2017-07-15 15:22:28

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#7 2017-07-15 15:56:51

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#8 2017-07-15 16:08:47

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#9 2017-07-15 16:15:57

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#10 2017-07-15 17:57:27

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#11 2017-07-16 07:59:13

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#12 2017-07-16 10:35:17

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#13 2017-07-16 16:21:41

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#14 2017-07-16 16:29:52

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#15 2017-07-16 20:21:22

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

#16 2017-07-16 23:13:03

Re: Cloning Devuan to a different partition updating linux-krnl initrd-img

Board footer