You are not logged in.
I had a similar problem, and Ralph's advice helped, but I had to delete those links a few times.
There are three hard drives in this computer. Up until a few months ago, when I plugged in a usb, it would be named /dev/sdd. Then one day it changed to /dev/sde. I've seen this in the past after pulling out a usb without unmounting it, but that always clears with a reboot. This has persisted.
I looked in /dev/disk/* and there were two links to /dev/sdd. One was 'Generic usb something' and the other was 'pci-something' that corresponded to the usb controller slot. I deleted those links two or three times, and they kept coming back. Then I deleted /dev/sdd along with them. That seems to have done it.
Thanks for persevering, dice. I gave up too soon. I did an install with targeted drivers and the initrd was only 8M, but maybe because the hardware was virtual. Let's see how this turns out, but I think you may have solved it.
Confirmed that ComputerBob's problem is not the same as yours. He has a full initrd.img (24M).
24M is big, and you confirmed that you didn't select for targeted drivers only. So that means your problem is not the same as dice's.
@ComputerBob:
When you return to this, here's a simple check to see if your problem is the same as dice's. Adjust the file name if you have a different kernel.
ls -lh /boot/initrd.img-4.19.0-14-amd64Do you recall if you did an expert install and chose to only have drivers targeted for your hardware in the initramfs? If you don't recall, that's fine. The output of the command above will tell us. It'll either be big or small. (I want the number, please.)
I think I found it. Move /etc/initramfs-tools/conf.d/driver-policy out of the way and run update-initramfs -u and then make a new snapshot.
Unpack the initramfs from the bad iso and also the one from the good iso and compare them. (Hint: meld is a good program for comparing files and directories.) Use unmkinitramfs instead of the commands I posted in that other thread. It's easier. Plus, the command I posted for computerbob won't work for your initrd.img.
Yeah, the second way is correct. I should have explained the quotes and $. Replace that with path to the file you're checking. And it looks good. The script removed crypttab and resume as it should have. I don't know what the next step is.
I have a couple of chimaera-based live isos here:
https://get.refracta.org/files/testing/
No xorg. No non-free. Run 'refractainstaller' to install to hard drive. Or do a debootstrap install.
Please do the same on either the mounted iso or mounted usb stick that has the image. Check /live/initrd.img to see if resume and crypttab got removed. Is the host system that made this snapshot an encrypted system?
lsinitramfs "$initrd.img" | egrep "resume|cryptroot|crypttab|askpass"Note: in the previous post I started the command with '#' which suggests it needs to be run as root, but that is not the case. You can run the command as user.
Sorry for the tease. That link might be one of my special powers as admin.
I don't understand the symlinks at all. When you looked at the mounted usb with ls, it showed the right things.
You can mount the iso as root and look at it that way.
mount /home/snapshot/snapshot.iso /mnt
ls /mnt
ls /mnt/live
ls /mnt/isolinux
# and when you're done looking around in there
umount /mntYou should see /live /isolinux /pkglist_whatever. Look inside /live and you should see initrd.img vmlinuz and filesystem.squashfs. Inside /isolinux should be live.cfg (the boot menu) and a bunch of other files that are the same ones in /usr/lib/refractasnapshot/iso/isolinux/.
Edit: you could do the same with the mounted usb and look inside the directories.
ls /media/computerbob/liveiso/live # and so on.The button is called "Edit".
rolfie
And if you are logged in, there's a link that says 'Mark SOLVED' just below the edit button and next to the link that says 'Post reply'.
Let's see what's in these two resume files. I don't understand why there are both of them. The first one is in older releases and then the name was changed to the second one in ascii or beowulf.
conf/conf.d/resume
conf/conf.d/zz-resume-autoIn order to get to those files, initrd.img needs to be extracted. Here are the commands to do that. Do this as unprivileged user in your home directory.
cp /initrd.img /home/computerbob/
mkdir extracted
cd extracted
(cpio -i ; zcat | cpio -i) < ../initrd.imgThen look in extracted/conf/conf.d/resume and zz-resume-auto
One or both will probably have the uuid of your swap partition. One or both might have RESUME=none. Or maybe something else I haven't thought of.
Don't delete the extracted stuff. It might be possible to fix and repack the initrd and plug it into the build process.
Bob, that output looks normal. If you want to get rid of the message about missing firmware, you could install firmware-misc-nonfree if you have non-free repositories enabled. (non-free refers to speech, not beer)
The real test will be to see if the new snapshot boots.
Multiple desktop environments doesn't work as easily as it used to. There are more dependency conflicts. You might have an easier time if you avoid metapackages. Instead of task-xfce-desktop or any of the others that get installed from the installation isos, install xfce4 or even install the individual parts. Same goes for the other desktops. That way you can resolve conflicts individually as they come up. Also, installing without Recommends will help with this.
If you just want to test different desktops, it might be cleaner to test in a virtual machine.
Default applications in the system are controlled by the alternatives system. Generally, the last app of any particular type that gets installed is the one that is preferred. See man update-alternatives and ls -l /etc/alternatives/ for more information.
n-m vs. wicd: In this case, it's the desktop environments that pulled them in. You could probably avoid this by installing things in pieces as described above.
Hi fsmithred, does refractasnapshot depend on having "initrd (initial ram disk): generic (all available drivers)" as opposed to "only select drivers to suit this hardware", during expert install? I have a feeling this is where the initramfs is failing.
Wow. Excellent question. I don't know the answer. I can't recall if this has ever come up in the 10 years I've been maintaining that script. I would expect a snapshot with limited drivers would only boot on the same or similar hardware.
That option is probably set in /etc/initramfs-tools/initramfs.conf. Compare the one with limited drivers to one with all available. If there's something obvious to change, change it, rebuild initramfs and make a new snapshot. update-initramfs -u
If you want to save time in the above procedure, make the new initrd.img and copy it to /home/work/iso/live and then run refractasnapshot, but choose the option to run xorriso only. You'll be done in one minute.
I don't think I've ever done an install with drivers limited to the current hardware. I always assume that my old boxen will die and I'll have to move the hard drive to another computer.
Edit: if you do the shortcut in this case, and you use that iso to install on another system, you will need to edit initramfs.conf in that system. That could be done in the live system before install. That way when the initrd gets rebuilt during the install it will be good.
Edit 2: change initramfs.conf in /home/work/myfs/ and run the re-squash option in refractasnapshot. That will avoid the problem mentioned in the first edit. It'll take longer, too.
I tried dice's qemu command (without the sudo) and my iso boots as cdrom or as disk. I'm pretty sure the problem is in the initramfs.
dice, please run:
lsinitramfs /initrd.img | egrep "resume|cryptroot|crypttab|askpass"
file -L /initrd.imgYou can probably read /boot.log from the initramfs prompt. Try more /boot.log I don't know a way to get it out of there.
And try this to boot the iso:
qemu-system-x86_64 -m 2560 -cdrom /home/snapshot/snapshot.isoYou don't need to be root or use sudo for that.
Perfect!!!
(embarrassed) Well, I have no idea what I'm doing, but you're giving me great instructions on how to do it all anyway, so I'm happy to (try to) do it!
root@robinson:~# lsinitramfs /initrd.img | grep resume conf/conf.d/resume conf/conf.d/zz-resume-auto scripts/local-premount/resume usr/bin/resume root@robinson:~# lsinitramfs /initrd.img | grep resume
Here's the fix.
1. Make a backup copy of /etc/initramfs-tools/conf.d/resume
If you don't ever hibernate your computer, this step is not really necessary.
2. As root, edit /etc/initramfs-tools/conf.d/resume so that it contains only the following:
RESUME=none
Save the file.
3. Run update-initramfs -u
4. Make a new snapshot.
5. (Optional) If you do use hibernate, you need to undo what you did. Copy the original resume file back to where it was and run 'update-initramfs -u' again. If you do that, you'll have to do this whole procedure every time you want to make a snapshot.
conf/conf.d/zz-resume-auto should have been removed but wasn't. I suspect you may have had conf/conf.d/resume as well, and that one did get removed. If so, I need to adjust the code in the snapshot script.
When you get back into the working installed system, please look inside the initramfs for that system.
lsinitramfs /initrd.img | grep resumeThanks.
I don't see anything helpful in the log. It all looks good. Are there any messages above the boot error other than the ones you posted?
Mount the usb and run
lsinitramfs /media/computerbob/liveiso/live/initrd.img | grep resumeto see if conf/conf.d/resume exists. It should not be there, and if it is, that may be the problem.
What you posted is strong evidence that the usb was imaged correctly. Use the email link to send me /var/log/refractasnapshot.log and I will look at it.
Right. You need to find the problem with the initrd. Look in the log to see what went wrong in the iso build process.
The symlinks that I mentioned are all on the USB stick itself. In Thunar, running on my actual HD, I don't see ANY actual files on that stick.
ls /media/computerbob/liveisolists the following
isolinux live pkglist_snapshot-20210311_1353
The ls command is seeing what is on the usb stick correctly. If you run df -h there should be a line that looks like this:
/dev/sdb1 807M 807M 0 100% /media/computerbob/liveisowith the size of your iso instead of mine.
maybe running locate boot.ini will tell us where that file really is.
You don't need to format the usb, but it can't hurt. Whether you use cat or dd to image the stick, make sure you write to the whole device (/dev/sdb) and not to a partition (/dev/sdb1).