Recent update, now only original antiX kernel will start? - Page 2

fatmac · posted: 2014-10-18 17:24

Seeing you still having problems with this, I have taken a look back to the start of the thread.
I am seeing mention of grub1 & grub2, these are totally different when it comes to configuring, which may be why you are getting problems.

Silent Observer · posted: 2014-10-18 21:05

male wrote:yes, I have already understood, that you have deleted the entry. __{{emoticon}}__

Afterwards you have to execute a
Code: Select all
update-grub
If your"Grub-configuration" is not capable of doing this, then you will have to get the right version.

Alternatively, in order for the new"kernel" to boot, you can always attach a USB Stick... __{{emoticon}}__
(translated by my daughter - my English is still not that good)

Yes, I ran update-grub after deleting the spurious entry in device.map, and then promptly deleted the unnecessary"automagic" stuff it added, along with the redundant entries for multiple start modes for each kernel. I'm still getting devices mounting with different identifiers showing in etc/mtab than they're given in etc/fstab, and the same failure when trying to boot kernel 3.12.6-antix.5-486-smp.

fatmac wrote:Seeing you still having problems with this, I have taken a look back to the start of the thread.
I am seeing mention of grub1 & grub2, these are totally different when it comes to configuring, which may be why you are getting problems.

The Athlon XP system has never had grub2 installed; the only Linux distro it's ever had installed is antiX 13.2 (though I checked out 13.1 from the Live CD a few times before installing, 13.2 was out by the time I jumped), and the only grub ever installed on it is what's now called Legacy Grub, the 0.97 version. I've never used Grub2 for any length of time on any system, and don't have it operating on any of my systems at this time.

rokytnji · posted: 2014-10-19 03:10

The Athlon XP system has never had grub2 installed; the only Linux distro it's ever had installed is antiX 13.2 (though I checked out 13.1 from the Live CD a few times before installing, 13.2 was out by the time I jumped), and the only grub ever installed on it is what's now called Legacy Grub, the 0.97 version. I've never used Grub2 for any length of time on any system, and don't have it operating on any of my systems at this time.

silentobserver posted;

Code: Select all

# dpkg --list | grep grub
ii  grub-common                          2.00-22                           i386         GRand Unified Bootloader (common files)
ii  grub-gfxboot                         0.97-48                           i386         GRand Unified Bootloader

WHICH might have confused fatmac so a

Code: Select all

apt-cache policy grub

in the previous reply might have cleared that up. While I am here. Give this kernel a try.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.linuxquestions.org/questions/dreamlinux-82/new-kernel-3-14-3-liquorix-zen-for-dreamlinux-5-and-debian-wheezy-4175505021/"
linktext was:"http://www.linuxquestions.org/questions ... 175505021/"
====================================

Maybe run that instead of the stock AntiX kernel. Then problem solved.
Just a suggestion though. While drinking a beer on a Saturday night.

Silent Observer · posted: 2014-10-19 11:32

rokytnji wrote:
The Athlon XP system has never had grub2 installed; the only Linux distro it's ever had installed is antiX 13.2 (though I checked out 13.1 from the Live CD a few times before installing, 13.2 was out by the time I jumped), and the only grub ever installed on it is what's now called Legacy Grub, the 0.97 version. I've never used Grub2 for any length of time on any system, and don't have it operating on any of my systems at this time.
silentobserver posted;
Code: Select all
# dpkg --list | grep grub
ii  grub-common                          2.00-22                           i386         GRand Unified Bootloader (common files)
ii  grub-gfxboot                         0.97-48                           i386         GRand Unified Bootloader
WHICH might have confused fatmac so a
Code: Select all
apt-cache policy grub

Well, that's interesting...

Code: Select all

$ dpkg --list | grep grub
ii  grub-common                          2.02~beta2-14                     i386         GRand Unified Bootloader (common files)
ii  grub-gfxboot                         0.97-48                           i386         GRand Unified Bootloader

How the heck did that get there? Well, it seems it's a dependency for Legacy Grub (aka 0.97-48), and carries the same version number as the current Grub 2...

This package contains common files shared by the distinct flavours of GRUB.
It is shared between GRUB Legacy and GRUB 2, although a number of files
specific to GRUB 2 are here as long as they do not break GRUB Legacy.

So, seemingly, shouldn't be a problem.

This, on the other hand, I don't fully understand:

Code: Select all

$ apt-cache policy grub
grub:
  Installed: (none)
  Candidate: (none)
  Version table:

I think this is because (for space reasons) I've got Synaptic set not to keep downloaded package files -- a setting that carries over to apt-get from a terminal (since Synaptic uses apt-get to install selected packages, it probably manages that setting with apt-get options).

While I am here. Give this kernel a try.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.linuxquestions.org/questions/dreamlinux-82/new-kernel-3-14-3-liquorix-zen-for-dreamlinux-5-and-debian-wheezy-4175505021/"
linktext was:"http://www.linuxquestions.org/questions ... 175505021/"
====================================

Maybe run that instead of the stock AntiX kernel. Then problem solved.
Just a suggestion though. While drinking a beer on a Saturday night.

I've had problems with some kernels not booting (kernel panic during startup) on this Athlon XP system, including the 3.14-0.bpo that runs so well on the Pentium II laptop. I haven't been interested in trying Liquorix kernels in the past, but I might check wheezy-backports to see if the bpo kernel works on this machine; it didn't originally on the laptop, but I'd left it installed (running 3.13-0.bpo from the same source) a while back and rechecked it after I noticed it getting updated in a dist-upgrade. If this is kernel version dependent, though, I'd expect it to give the same problems with 3.13 and 3.14 as with 3.12.

What I'm after is specifically why partitions are trying to mount with different identifiers than the ones I've given them in fstab, in newer kernel but not in 3.7.10-antix-2, and how to correct this.

Edit: Okay, I'm now running kernel 3.14-0.bpo.2-686-pae, and it started right up (significantly faster starting than 3.7.10, I might add, and seems faster running overall). That solves the operational problem, but but doesn't really answer the question about what was making 3.12.6-antix.5-486-smp misbehave. In fact:

Code: Select all

$ cat etc/mtab
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,relatime 0 0
udev /dev devtmpfs rw,relatime,size=10240k,nr_inodes=126562,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=622,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=206412k,mode=755 0 0
/dev/disk/by-label/Luddite / ext4 rw,noatime,data=ordered 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=21,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/sda4 /home ext4 rw,noatime,data=ordered 0 0
rpc_pipefs /run/rpc_pipefs rpc_pipefs rw,relatime 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=103208k,mode=700,uid=1000,gid=1000 0 0

As you can see, the mismounting is still going on (/home on /dev/sda4 should be mounted the same way as root, using /dev/disk/by-label), but this kernel tolerates it.

male · posted: 2014-10-19 18:36

The fact is,
they are with their theory mtab on the wrong track.

The fact is,
you have an inconsistent system regarding Grub due own configurations.

The fact is,
they give different information to

Code: Select all

update-grub

times YES, NO times, sometimes inaccurate

I have one last tip (just here on an identical System with kernel 3.7.10-smp-antix.3-486 successfully tested)

To remove such an entry from the device.map and"make known" with the new kernel

you can run

Code: Select all

grub-mkdevicemap

and then

Code: Select all

update-grub

__{{emoticon}}__

Silent Observer · posted: 2014-10-20 00:57

male wrote:The fact is,
they are with their theory mtab on the wrong track.

The fact is,
you have an inconsistent system regarding Grub due own configurations.

You're saying (I think) that I've misconfigured something, but this system ran well for many months, then (without changes other than downloading weekly dist-upgrade packages) started giving this trouble. I don't know for certain that mtab ever matched the UUID settings in fstab; I've never had reason to look at it before (though I've found, by experiment, that deleting or replacing mtab, which is a link to /proc/mounts, which itself is a link to the inaccessible self/mounts, results in the link being restored, by deletion of the replacing file if present).

The fact is,
they give different information to
Code: Select all
update-grub
times YES, NO times, sometimes inaccurate

I have one last tip (just here on an identical System with kernel 3.7.10-smp-antix.3-486 successfully tested)

To remove such an entry from the device.map and"make known" with the new kernel

you can run
Code: Select all
grub-mkdevicemap
and then
Code: Select all
update-grub
__{{emoticon}}__

Testing this now; I'm booting the Athlon XP to the 3.12.6 kernel to verify the problem still exists. I got a message during an install today that said something was broken, and I might need to rerun my bootloader, but the update terminal had accidentally been marked to close when complete, and closed before I could be certain of the entire message. Installing another similar package didn't repeat the message, leading me to suspect whatever it was had been resolved by the automatic update-initramfs done during a kernel install.

And yes, the 3.12.6 kernel still boots to"emergency mode" via the 1:30"start job" for /home and swap partitions (failing). I should be able to run the above commands in the resulting root login: issuing grub-mkdevicemap gave no error, and cat /boot/grub/device.map lists fd0 and hd0 with legit-seeming identifiers (hd0 is by-id with what looks like Seagate's model identifier). Issuing update-grub gives a list of found kernels, plus memtest86 and Windows 98; listing out menu.lst with cat shows my old version at the top, then the block of"automagic" comment blocks, followed by the additional boot options for detected kernels. No difference from any previous run. Now, let me reboot that system.

Booting to 3.12.6 kernel results in the same"start job" for /home and swap. Nothing changed by grub-mkdevicemap followed by update-grub. If the information in mtab is unimportant, how to explain that the partition that isn't mounted the way I specify in fstab is failing to mount for this kernel? I don't think mtab causes anything -- it's a status display, of sorts, nothing more, but it's accurately reporting the failure of two partitions to mount correctly during startup.

FWIW, once in emergency mode, I'm able to manually mount /dev/sda4, and it correctly shows in mtab as /home, but shows only by device name, not by either UUID or label. The failure to complete mounting /home and swap by label or UUID appears to be a bug that affects (of those I have installed) only kernel 3.12.6-antix.2-486-smp. I just don't get how that kernel ran correctly for months (with UUID in fstab), and just started failing last weekend.