You are not logged in.
Hmm, there you see the disadvantage of me not actually testing the commands. It needs the -u as well as -k all.
(again edited the original; only a few commands to go )
Offline
OK, this is what I got:
# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
mkinitramfs: failed to determine device for /
mkinitramfs: workaround is MODULES=most, check:
grep -r MODULES /etc/initramfs-tools/
Error please report bug on initramfs-tools
Include the output of 'mount' and 'cat /proc/mounts'
update-initramfs: failed for /boot/initrd.img-3.16.0-4-amd64 with 1.
If the message is referring to the previous commands, there was no output, everything went smoothly, this time.
Here is what my /etc/initramfs-tools/modules file looks like:
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax: module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
ehci-pci
ehci-orion
uhci-hcd
Last edited by devuan_dk_fan (2018-01-26 12:04:31)
Military justice is to justice what military music is to music. - Groucho Marx
I’ve had a perfectly wonderful evening, but this wasn’t it. - Groucho Marx
Offline
Ok. I don't know why the initrd building worries about the device node, since it should just take what is given at boot time, and not at building time. There might be a number of gremlins under that stone, but maybe you get away with just rolling back and mounting devtmpfs onto /dev before another update-initramfs.
# mount -t devtmpfs none /dev
By idle guesswork, I think the initrd building really would want to find a file /var/lib/initramfs-tools/3.16.0-4-amd64 with content:
fd47cef5-ce5e-4090-8bfa-aef277a49e3e /boot/initrd.img-3.16.0-4-amd64
as its "database entry" of where that initrd is supposed to reside. But it burns my synapses trying to fathom an underlying logic for it.
Anyhow, maybe it'll be happy enough with having devtmpfs mounted.
Offline
As suggested by update-initramfs, run grep -r MODULES /etc/initramfs-tools/ to make sure one of the files in that directory contains "MODULES=most". (probably initramfs.conf. That's where it is on my jessie.)
It's probably not anything to do with usb. Those error messages seem to come up a lot when the initrd fails right before it switches root.
Try lsinitramfs /boot/initrd.img-3.16.0-4-amd64 | grep resume Check to see there is a file, conf/conf.d/resume. I've seen similar problems when that file contains a uuid that no longer exsits.
FWIW, I use the following commands for chroot (where ${chroot_dir} is wherever you mount the partition):
mount --bind /sys ${chroot_dir}/sys
mount --bind /proc ${chroot_dir}/proc
mount --bind /dev ${chroot_dir}/dev
mount --bind /dev/pts ${chroot_dir}/dev/pts
Offline
No luck There were no errors in the process at all, and there wasn't much feedback when I booted into the Devuan system either. The only thing that looked like an error was:
/bin/sh: can't access tty: job control turned off
Here is the relevant information from the process:
# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
Smooth. Relevant /etc/fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sdd1 during installation
UUID=f73498af-846e-447a-87d7-4f0b0b01818d / ext4 errors=remount-ro 0 1
# /home was on /dev/sdd6 during installation
UUID=cf653dd3-5fc1-4f64-911c-cca7ee3ce248 /home ext4 defaults 0 2
# swap was on /dev/sdd5 during installation
UUID=c6c5dab4-b097-4db1-a50a-e79e5c8628e5 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
Relevant /boot/grub/grub.cfg info:
$ sudo nano /boot/grub/grub.cfg
menuentry "unknown Linux distribution (on /dev/sdd1)" --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-f73498af-846e-447a-87d7-4f0b0b01818d' {
insmod part_msdos
insmod ext2
set root='hd3,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd3,msdos1 --hint-efi=hd3,msdos1 --hint-baremetal=ahci3,msdos1 f73498af-846e-447a-87d7-4f0b0b01818d
else
search --no-floppy --fs-uuid --set=root f73498af-846e-447a-87d7-4f0b0b01818d
fi
linux /boot/vmlinuz-3.16.0-4-amd64 root=/dev/sdd1
initrd /boot/initrd.img-3.16.0-4-amd64
Extra credit work:
# grep -r MODULES /etc/initramfs-tools/
/etc/initramfs-tools/initramfs.conf:# MODULES: [ most | netboot | dep | list ]
/etc/initramfs-tools/initramfs.conf:MODULES=most
/etc/initramfs-tools/conf.d/driver-policy:MODULES=dep
# lsinitramfs /boot/initrd.img-3.16.0-4-amd64 | grep resume
scripts/local-premount/resume
bin/resume
conf/conf.d/resume
Military justice is to justice what military music is to music. - Groucho Marx
I’ve had a perfectly wonderful evening, but this wasn’t it. - Groucho Marx
Offline
Did you try changing the grub line? Into
linux /boot/vmlinuz-3.16.0-4-amd64 root=UUID=f73498af-846e-447a-87d7-4f0b0b01818d
so as to completely avoid referring to /dev/sdd1
Offline
No error message at all that I can see, but it stops at the line:
[ 9.003419] IPV6: ADDRCONF (NETDEV_CHANGE): eth0: link becomes ready
Military justice is to justice what military music is to music. - Groucho Marx
I’ve had a perfectly wonderful evening, but this wasn’t it. - Groucho Marx
Offline
Edit: This should be first. When you get to
'[ 9.003419] IPV6: ADDRCONF (NETDEV_CHANGE): eth0: link becomes ready"
Press ENTER to see if you get a command prompt, or press alt-F2 to see if you get a console login screen.
OK, that's the end of the edit. Original message is below.
-------
conf/conf.d/resume
To see what's inside resume, you'll need to extract the initrd. You can do this as ordinary user.
mkdir extracted
zcat /boot/initrd.img-3.16.0-4-amd64 | cpio -i
cat conf/conf.d/resume
It might contain a reference to a wrong or non-existent partition.
If you change or remove that file to make a modified initrd, repack it (as user)
find . -print0 | cpio -0 -H newc -o | gzip -c > ../custom-initrd
You'll have a file named custom-initrd in the directory above extracted.
Then make a backup copy of the existing initrd and copy the new one into place. (su to root or use sudo)
cp /boot/initrd.img-3.16.0-4-amd64 /boot/initrd.img-3.16.0-4-amd64.bak
cp ../custom-initrd /boot/initrd.img-3.16.0-4-amd64
Cross fingers and reboot.
Offline
OK, I was able to get a command prompt. Here are the results:
$ zcat /boot/initrd.img-3.16.0-4-amd64 | cpio -i
20210 blocks
$ cat conf/conf.d/resume
cat: /conf/conf.d/resume: No such file or directory
I don't really understand this as the
# lsinitramfs /boot/initrd.img-3.16.0-4-amd64 | grep resume
command above listed a conf/conf.d/resume file.
On the off chance, I chrooted back into the Devuan system, to check that out with the following as I couldn't find any /conf/conf.d directory:
# nano /etc/initramfs-tools/conf.d/resume
RESUME=UUID=c6c5dab4-b097-4db1-a50a-e79e5c8628e5
Sooo, if this is the correct "resume" file, the UUID agrees with that in the /etc/fstab that I posted earlier. However, only the system swap UUID is listed. I am not sure if that is to be expected or not...
Last edited by devuan_dk_fan (2018-01-27 09:30:42)
Military justice is to justice what military music is to music. - Groucho Marx
I’ve had a perfectly wonderful evening, but this wasn’t it. - Groucho Marx
Offline
Great. I think. The command prompt may well be post-pivot, which would mean that you actually have booted Devuan, but that there is an issue with the graphics. A few things to inspect:
# blkid
# dmesg | tail
# tail /var/log/syslog
# ls -l /dev/sd*
Though, I'd say fsmithred has more experience about getting it back into shape from this state, so maybe you should now ignore me
Offline
Off the bat, I would say that there probably is an issue with the graphics, as I haven't installed any yet. The system for now is pure cli. I am still unsure as to whether I will try an upgrade to ascii. That depends on a couple of things. Firstly, after this experience so far, if there is a consensus that I would be able to get a stable, Devuan Jessie system installed as my main system (erasing Linux Mint), with less wrestling than this time around. The other would be whether there would be interest from the Devuan developer team, that I joined the testers. I am not sure whether I have enough experience to find my way through the ins and outs of testing a system, but am willing to use the system we are now sorting out and give it a try.
Last edited by devuan_dk_fan (2018-01-27 13:17:05)
Military justice is to justice what military music is to music. - Groucho Marx
I’ve had a perfectly wonderful evening, but this wasn’t it. - Groucho Marx
Offline
# blkid
# dmesg | tail
# tail /var/log/syslog
# ls -l /dev/sd*
What the #%!?:
# mount /dev/sdd1 /mnt/devuan
# chroot /mnt/devuan
chroot: failed to run command ‘/bin/bash’: No such file or directory
# cd /mnt/devuan
# ls -l
total 4
drwxrwxrwx 1 root root 0 Nov 9 18:05 $RECYCLE.BIN
drwxrwxrwx 1 root root 4096 Nov 19 00:04 System Volume Information
OK, this is freaky.
Interesting. I restarted and booted from the Devuan install, to see if it actually was there in practical terms. It was, but when I ran
# blkid
, I discovered that /dev/sdd1 had suddenly become /dev/sde1. Now that I have booted back into Linux Mint, Devuan has again become /dev/sdd1, so here is the info that you requested (as it occurred):
# blkid
# dmesg | tail
[ 471.108262] [UFW BLOCK] IN=enp5s0 OUT= MAC=70:85:c2:2c:00:8c:f4:f5:d8:30:9b:1e:08:00 SRC=192.168.8.106 DST=192.168.8.102 LEN=545 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=60820 DPT=44372 LEN=525
[ 472.132189] [UFW BLOCK] IN=enp5s0 OUT= MAC=70:85:c2:2c:00:8c:f4:f5:d8:30:9b:1e:08:00 SRC=192.168.8.106 DST=192.168.8.101 LEN=545 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50198 DPT=57853 LEN=525
[ 472.133077] [UFW BLOCK] IN=enp5s0 OUT= MAC=70:85:c2:2c:00:8c:f4:f5:d8:30:9b:1e:08:00 SRC=192.168.8.106 DST=192.168.8.102 LEN=545 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50441 DPT=44372 LEN=525
[ 486.324034] EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)
[ 490.991139] [UFW BLOCK] IN=enp5s0 OUT= MAC=70:85:c2:2c:00:8c:f4:f5:d8:30:9b:1e:08:00 SRC=192.168.8.106 DST=192.168.8.101 LEN=545 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=60128 DPT=52343 LEN=525
[ 590.105123] [UFW BLOCK] IN=enp5s0 OUT= MAC=70:85:c2:2c:00:8c:f4:f5:d8:30:9b:1e:08:00 SRC=192.168.8.106 DST=192.168.8.101 LEN=545 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=49928 DPT=38245 LEN=525
[ 590.112020] [UFW BLOCK] IN=enp5s0 OUT= MAC=70:85:c2:2c:00:8c:f4:f5:d8:30:9b:1e:08:00 SRC=192.168.8.106 DST=192.168.8.102 LEN=545 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=36646 DPT=42260 LEN=525
[ 591.128277] [UFW BLOCK] IN=enp5s0 OUT= MAC=70:85:c2:2c:00:8c:f4:f5:d8:30:9b:1e:08:00 SRC=192.168.8.106 DST=192.168.8.101 LEN=545 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=43221 DPT=38245 LEN=525
[ 591.131539] [UFW BLOCK] IN=enp5s0 OUT= MAC=70:85:c2:2c:00:8c:f4:f5:d8:30:9b:1e:08:00 SRC=192.168.8.106 DST=192.168.8.102 LEN=545 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=45125 DPT=42260 LEN=525
[ 592.147389] [UFW BLOCK] IN=enp5s0 OUT= MAC=70:85:c2:2c:00:8c:f4:f5:d8:30:9b:1e:08:00 SRC=192.168.8.106 DST=192.168.8.101 LEN=545 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=33948 DPT=38245 LEN=525
# tail /var/log/syslog
Jan 27 14:25:22 computer dbus[1701]: [system] Failed to activate service 'org.freedesktop.Avahi': timed out
Jan 27 14:25:47 computer dbus[1701]: [system] Activating service name='org.freedesktop.ConsoleKit' (using servicehelper)
Jan 27 14:25:47 computer dbus[1701]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper)
Jan 27 14:25:47 computer polkitd[2168]: started daemon version 0.105 using authority implementation `local' version `0.105'
Jan 27 14:25:47 computer dbus[1701]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Jan 27 14:25:47 computer dbus[1701]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Jan 27 14:27:23 computer shutdown[2199]: shutting down for system reboot
Jan 27 14:27:23 computer init: Switching to runlevel: 6
Jan 27 14:27:26 computer acpid: exiting
Jan 27 14:27:27 computer rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="1498" x-info="http://www.rsyslog.com"] exiting on signal 15.
# ls -l /dev/sd*
ls: cannot access /dev/sd*: No such file or directory
Last edited by devuan_dk_fan (2018-01-27 14:42:13)
Military justice is to justice what military music is to music. - Groucho Marx
I’ve had a perfectly wonderful evening, but this wasn’t it. - Groucho Marx
Offline
Welcome to grub hell. GRUB and the kernel don't always agree on what is the first disk.I need to reply a few posts back before I even think about your last post.
cat /conf/conf.d/resume would give the error you got. Are you sure you didn't use a leading slash?
If you're in the extracted directory, cat conf/conf.d/resume should output the same line that's in /etc/initramfs-tools/resume and that should be your swap partition's uuid. It gets used when you return from hibernation to disk.
OK, back to the immediate problem. Do you change the order of the disks when you boot the diffrerent systems? That could be done by going into the bios and changing the hard disk order or by calling up the boot device menu and selecting different disks before the grub menu comes up.
Are you booting from usb on any of these occasions? GRUB will probably see the usb as hd0 when you do, and all the internal disks get bumped up one number.
As I understand it, right now you are using mint's grub to boot devuan. If you want to get rid of mint, you'll need to use devuan's grub to boot. Are you going to change the order of the hard disks when you do?
I'm posting this now, before I tell you to do something wrong.
Offline
OK, I must have made a mistake. This time I get:
$ cat conf/conf.d/resume
RESUME=UUID=c6c5dab4-b097-4db1-a50a-e79e5c8628e5
Which confirms what I found with
# nano /etc/initramfs-tools/conf.d/resume
earlier.
No, I don't normally change the order, but that would happen if and when I burn a new .iso file to USB pen drive, and install a new system. However, I haven't done that since I re-installed a Devuan minimum cli system and we started on trying to get these problems sorted.
I am hoping to eventually install a Devuan Jessie (stable) system on my /dev/sda drive, but I would like to do some more testing if possible before I take that step, particularly considering the complexities of the current situation.
You and Ralph deserve a big thank you for what you have done so far.
Last edited by devuan_dk_fan (2018-01-27 16:28:17)
Military justice is to justice what military music is to music. - Groucho Marx
I’ve had a perfectly wonderful evening, but this wasn’t it. - Groucho Marx
Offline
Cool! We're almost there.
Here's my quick summary of the situation.
- You can boot from the mint grub if you specify root=uuid.
- The resume file contains a valid uuid for your swap partition, and boot isn't hanging with a message about not being able to find some uuid that doesn't exist.
- We don't know Who's on first base.
What I would do first is boot into devuan the way you did.
- Run 'fdisk -l' to see if devuan is on /dev/sdd1 today. If it is, run
grub-install /dev/sdd
and if it's not on sdd, then use whatever it's calling itself. (whole drive, not partition)
- Reboot and press whatever key gets you the boot device menu. Might be F8 or F12, might be ESC or something else. It should tell you on screen before you get to the grub menu. When you get there, choose the drive with devuan on it. That will temporarily make it the first drive, and you should get to devuan's grub menu. Boot the first option (Devuan) to make sure it really works.
This should all work perfectly, and it will show you that devuan can boot itself from the first hard disk.
Next step - I give you special powers to turn you into a super-gnuru.
Reboot, do not go to the boot device menu. Just go to the mint grub menu.
Press "c"
You will get a prompt that says: grub>
Type the following, and then press TAB a couple of times.
set root=(hd0
You'll get a list of partitions. You should be able to figure out which disk grub is calling hd0.
Erase the 0 and replace it with 1. Press TAB a couple of times. Repeat with 2 and 3.
Once you figure out what mint's grub wants to call the disk with devuan on it, enter the following commands. We expect it to be (hd3,msdos1) but it probably won't be. I'll just use that for the example, but you should use what you find.
set root=(hd3,msdos1)
linux /vmlinuz ro root=/dev/sdd1 #change this to wherever it is according to the previous command.
initrd /initrd.img
boot
It should boot into devuan.
If you want a menu entry for devuan in the mint boot menu (one that works, I mean) you can create a custom one.
Boot mint.
Edit /etc/grub.d/40_custom and add
menuentry 'Devuan on sdd1' {
set root=(hd3,msdos1) # or wherever it is
linux /vmlinuz ro root=/dev/sdd1 # or use the root=uuid here
initrd /initrd.img
}
Save the file and run update-grub. It will be added to mint's boot menu.
That's all.
Offline
Here is the latest. I booted into the Devuan partition via the LM GRUB menu.
# fdisk -l
/dev/sde1
/dev/sde2
/dev/sde3
/dev/sde4
# grub-install /dev/sde
greb-install command not found
Commented out the CD:
# nano /etc/apt/sources.list
# dhclient eth0 -v
# apt install grub
grub-common grub-legacy libs yadayada
searching for grub-install directory... found /boot/grub
list of partitions
The file /boot/grub/stage1 not read correctly
So that ended the latest attempt. I did notice however, that fdisk -l kicked up an error on the extended partition:
"Partition 2 does not start on physical sector boundary" Not sure if it is important or if something should be done.
Military justice is to justice what military music is to music. - Groucho Marx
I’ve had a perfectly wonderful evening, but this wasn’t it. - Groucho Marx
Offline
The warning about the physical boundary should not be a problem. But I think you should be using grub-pc (grub2). I don't think grub-legacy can handle ext4 partitions.
Offline
OK, things have gone a bit pear shaped. I booted back into Devuan, I ran fdisk-l to determine which hard disk to install grub-pc to. I was told /dev/sde. I then purged grub-legacy before I installed grub-pc. . During the detection of other partitions, I got the following:
Found Windows 10 /dev/sdb1
Found Linux Mint 18.3 Sylvia (18.3) on /dev/sde1
I then rebooted and as my hard discs were more or less purchased at the same time, same brand, and specs, I had to use the boot menu more or less trial and error. At some point, Windows 10 came up. I restarted and now the BIOS boot menu no longer works - at all. However, a Devuan GRUB comes up as default. From that, I can also boot into Linux Mint. When I boot into Devuan, I get an error about the "orion" module and then come a bunch of USB errors. My main concern however, is of course the BIOS boot menu that no longer works.
Last edited by devuan_dk_fan (2018-01-28 09:51:30)
Military justice is to justice what military music is to music. - Groucho Marx
I’ve had a perfectly wonderful evening, but this wasn’t it. - Groucho Marx
Offline
After a couple of reboots to get the full error messages in Devuan, the BIOS boot menu seems to be working again - hesitantly.
The "orion" error reads:
module ehci-orion not found in modules.dep
The USB error reads:
USB 7-3: device descriptor read/64, error-110
Interestingly, Linux Mint gives me the same error at boot. Can I assume this is something that Win 10 did?
Supposedly, the "solution" is to power down, unplug all USB devices and let the computer sit for awhile. Time Will tell.
Last edited by devuan_dk_fan (2018-01-28 11:41:46)
Military justice is to justice what military music is to music. - Groucho Marx
I’ve had a perfectly wonderful evening, but this wasn’t it. - Groucho Marx
Offline