You are not logged in.
Pages: 1
So I have been mulling this over and there's an actual case now of a user that could use such, so Fsmithred suggested I start a thread on it so we wouldn't clutter up that thread, so this is it. I am mostly here to pick FSR's brain, lol!
I know that trying to roll a 4.9 kernel snapshot requires some newer packages, but I am wondering if I can add the 4.9 kernel from backports to a jessie system, but retain the 3.16 kernel and run snapshot during the 3.16 session, and then (with some grub-live editing) be able to offer either kernel as a choice to boot the live session?
The user in question that has an issue, needs a newer piece of firmware for wi-fi, Intel 3965 I think it was which only works with 4.11 kernel and up, wondering if those couple of tiny chunks of firmware would work if you manually installed them in the firmware directory and booted the 4.9 kernel?
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Bummer, gonna have to put this on the backburner again before I even get started, lol.
4.9 kernel from backports will no longer install for me, it's asking for linux-base>=4.3, and the only thing available in jessie (including backports) is version 3.5.
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Me too. Up until three days ago (I think), adding a newer kernel from backports was a piece of cake. I tried installing it a couple of days ago, and hit the same issue. After much finagling, I eventually got it installed, but lost wifi afterward. Wasn't interested in trying to figure it out after that...
I have been Devuanated, and my practice in the art of Devuanism shall continue until my Devuanization is complete. Until then, I will strive to continue in my understanding of Devuanchology, Devuanprocity, and Devuanivity.
Veni, vidi, vici vdevuaned. I came, I saw, I Devuaned.
Offline
I hear that 4.4 may work, I haven't tried. You may have to compile it on your own and that may not be a good thing for includiing it in a live image as it may not work on other machines.
But why not just pull the necessary dependencies for the kernel from ascii and see how it works.
Offline
As I mentioned in another thread, you need to tell apt to install linux-base from backports when you install the bpo kernel.
apt-cache policy linux-base
linux-base:
Installed: 3.5
Candidate: 3.5
Version table:
4.5 0
100 http://us.mirror.devuan.org/merged/ ascii/main amd64 Packages
100 http://auto.mirror.devuan.org/merged/ ceres/main amd64 Packages
4.3~bpo8+1 0
200 http://packages.devuan.org/merged/ jessie-backports/main amd64 Packages
*** 3.5 0
500 http://debian.csail.mit.edu/debian/ jessie/main amd64 Packages
100 /var/lib/dpkg/status
On to the main topic. (I haven't done this in a long time, so you're getting the quick version.)
Install both kernels in the host system.
Make a snapshot (with save_work="yes")
Whichever kernel is symlinked with /vmlinuz will be in the copy. (same with initrd) That will likely be the backports kernel.
Copy the other kernel and initrd into place. Something like
cp /boot/vmlinuz-3.16-blah /home/work/iso/live/vmlinuz1
cp /boot/initrd.img-3.16-blah /home/work/iso/live/initrd1
Edit your boot menus to add stanzas for vmlinuz1 and initrd1.
Re-run refractasnapshot and choose the 4th option (re-run xorriso, no-copy, no-squash)
Potential problem (that you already thought of): 4.9 kernel needs newer live-boot and live-config than the one used by 3.16. The older version of live-* uses aufs and the newer uses overlay. The reason the newer kernel needs the newer live-* is because aufs is not in the kernel.
I don't know if 3.16 will work with newer live-* packages. If it does, you'll only have to do this once. (in theory)
Other option would be to recompile the 4.9 kernel and add aufs support. Then you could use the older live-* packages.
Oh... just thought of another way to do it.
Make an iso with 3.16, put it on a usb (using refracta2usb) and create two persistent loopback files (with full persistence). Make them big so you can install packages.
Keep one persistent volume for running 3.16.
Boot the other persistent volume and add the backports kernel and live-* packages.
Go back to the host system, mount the usb, mount the loopback file with the bpo kernel and copy that vmlinuz and initrd into the /live dir as described above.
Then dd the usb stick into a file (named something.img). File size might be an issue in regards to upload and download.
Offline
Maybe this question is appropriate here as well, I asked elsewhere and did not get any responses.
You install jessie and you build your system. eth0 and wlan0 are on. You upgrade to ascii and clean it up and make an iso via refracta. You boot the live system, all is well, but the network has switched to long names ?
Did you check whether that was the problem?
$ sudo ifconfig -a (look for the eth and wl names and add it to the next command).
$ sudo ifconfig wl4520jh02^(*&^ up
Why does this change from the system to the live, and I bet it stays like this when reinstalled.
All information of how to revert this I have found is for systemd and does not apply to us.
Last edited by fungus (2017-08-26 12:06:52)
Offline
Easy fix for the change in network names - revert to the old names by adding "net.ifnames=0" to the boot command.
You can add it to /etc/default/grub, next to "quiet" (will only affect the default boot choice) or in the line below (will affect all boot entries.)
Before making a snapshot, add it to /usr/lib/refractasnapshot/iso/isolinux/live.cfg (ang grub.cfg.template if you're enabling uefi boot.)
Note: this will be a config option in a future version of snapshot.
Note2: It's likely that eudev will be configured to reverse this behavior (i.e. you'll need net.ifnames=1 if you want the new names.)
Offline
On my 2 devuan installations both ascii, they are both eth0 and wlan0
So before I spend an hour or two to see if it would reverse the effect on the live I thought it would be faster if
I tried to get the one installed to get the long names. As the first line didn't affect it I added the second, although
I bootted from default. Neither try got the long names.
GRUB_CMDLINE_LINUX_DEFAULT="quiet","net.ifnames=1"
GRUB_CMDLINE_LINUX="net.ifnames=1"
On refracta would this be the correct format?
label live
menu label ${DISTRO} (default)
kernel /live/vmlinuz
append initrd=/live/initrd.img boot=live net.ifnames=0 ${netconfig_opt} ${username_opt}
On another distribution with OpenRC it has the long names. It also has network-manager
I tried the same as above but with net.ifnames=0 and rebooted. No difference, still got the long ones.
Offline
It's likely that eudev will be configured,,,
Future tense. It actually might already be in the latest build of eudev, but I'm not sure if that's in the repo yet. Need to check parazyd's test repo.
The live-boot stanza is correct.
Offline
Now I feel dumb, that was really easy to fix
Here are the complete instructions:
Edit your /etc/default/grub change GRUB_CMDLINE_LINUX="" to :
GRUB_CMDLINE_LINUX="net.ifnames=0"
If the biosdevname is installed you need to add :
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
update-grub
This creates a new /boot/grub/grub.cfg and for each entry in the line that starts with Linux there is a net.ifnames=0 usually after rw and the uuid address, so you can even add it manually there and reboot to see if the longnames have vanished and eth0 and wlan0 have re-established themselves.
Offline
Pages: 1