You are not logged in.
Pages: 1
Hi there:
Is there a known issue with the current arch kernel and ext2 filesystem?
I updated my Arch with pacman a week ago, fed the new image to lilo and since then cannot boot anymore.
On the first reboot I got a message like XFS mounting ...
From my 2nd Linux I added
append root=/dev/sdb2 rootfstype=ext2 ...
but still kinit is panicing.
Haven't changed anything in my setup (fstab ...) besides the new kernel pacman provided.
Before abandoning Arch alltogether: would it work to manually provide a new kernel + initrd + /lib/modules
from outside?
Thanks in advance!
Offline
Hi there:
On the first reboot I got a message like XFS mounting ...
From my 2nd Linux I addedappend root=/dev/sdb2 rootfstype=ext2 ...
but still kinit is panicing.
Post your /etc/lilo.conf, /etc/fstab, and the output of fdisk -l.
Sounds like you're lilo.conf might be incorrect because of a change in drive order or something. Therefore your / fs might no longer be on /dev/sdb2.
Also "root" as passed in the kernel commandline, refers to the partition that holds the filesystem mounted at / , but not necessarily the kernel, which might reside in a separate fs mounted at /boot. I very much doubt that your root fs is formatted ext2, although /boot may be.
Also, your lilo.conf syntax is incorrect. It should be
append="root=/dev/sdxx"
where xx is your partition
and the "rootfstype=" kernel option forces a fs to be mounted as a particular type. I'm guessing that you are trying to force and XFS fs to be mounted as ext2, which won't work.
And no, a new kernel wouldn't help, it's a problem with your configuration, not the kernel.
Offline
Thanks for the quick reply!
> Post your a) /etc/lilo.conf, b) /etc/fstab, and c) the output of fdisk -l.
a)
# /etc/lilo.conf
# Start LILO global section
boot=/dev/sdb2
disk=/dev/sdb bios=0x81
# disk=/dev/hdb bios=0x81 sectors=63 head=255 cylinder=16065
# disk=/dev/hdb bios=0x81
# compact # faster, but won't work on all systems.
default=arch
timeout=180
lba32
prompt
# VESA stuff goes here ..
...
image=/boot/vmlinuz26
label=arch
# root=/dev/disk/by-uuid/e1bb42e5-67c6-40e6-811c-976950c14472
append="root=/dev/sdb2 rootfstype=ext2"
initrd=/boot/kernel26.img
read-only
...
# other OS's
...
After some reearch I've also tried to comment out lba32 - without success.
b)
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
# none /dev/pts devpts defaults 0 0
# none /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
shm /dev/shm tmpfs nodev,nosuid 0 0
UUID=e1bb42e5-67c6-40e6-811c-976950c14472 / ext2 defaults 0 1
/dev/sdc2 swap swap defaults 0 0
/dev/sdb6 swap swap defaults 0 0
UUID=0415fce2-b72d-46db-8277-d173b417442a /home xfs defaults 0 1
/dev/sdc4 /mnt/scsiext2 ext2 defaults 0 1
tmpfs /tmp tmpfs defaults,noatime,size=192m 0 0
# other fs' go here
...
c)
cfdisk (util-linux-ng 2.14.2)
Disk Drive: /dev/hdb
Size: 251000193024 bytes, 251.0 GB
Heads: 255 Sectors per Track: 63 Cylinders: 30515
Name Flags Part Type FS Type [Label] Size (MB)
--------------------------------------------------------------------------------------------
hdb1 Primary W95 FAT32 (LBA) 12889.02
hdb2 Primary Linux ext2 21476.21
hdb3 Boot Primary FreeBSD 32209.94 *
Logical Free Space 0.27 *
hdb5 Logical NTFS [^G] 64428.62
hdb6 Logical Linux swap 1612.16
hdb7 Logical Linux ext3 21476.21
hdb8 Logical W95 FAT32 12889.02
hdb9 Logical Linux XFS 84013.01
Note this is from a different OS (Arch doesn't boot), i.e. Slackware, so you have to translate hdb into sdb, in Arch language.
> Sounds like you're lilo.conf might be incorrect because of a change in drive order or something. Therefore your / fs might no longer be on /dev/sdb2.
Well, as I said, I haven't changed my setup, besides running pacman
Also note that h(s)db9 is indeed XFS, and in use as my /home fs.
> I very much doubt that your root fs is formatted ext2, although /boot may be.
No "/boot" partition on this system!
> Also, your lilo.conf syntax is incorrect. It should be ...
Sorry for the mistake, it's correct in /etc/lilo.conf
> I'm guessing that you are trying to force and XFS fs to be mounted as ext2, which won't work.
I don't think so - unless gremlins have changed my setup. But then Slackware boots just fine ...
I mentioned in my original posting that the"rootfstype=ext2"" was added only after Arch wouldn't
boot anymore, as a consequence of a pacman / kernel -update.
> And no, a new kernel wouldn't help, it's a problem with your configuration, not the kernel.
Hmh, I'm thinking of copying over /boot/vmlinuz + /boot/initrd + /lib/modules/kernel-version
from my Slack install, and create an appropriate entry in lilo.conf. And then hope that the
next pacman delivers a compatible kernel ...
An other option might be trying out grub, but to me it always seemed a bit shaky compared
to 'good old' lilo.
Btw, one of the last boot messages reads
kinit: Unable to mount root fs on dev(8,18)
kinit: init not found
Can you tell what 'dev(8,18) stands for? Certainly not bios drive numbering ...
Last edited by bunc (2010-01-30 21:47:51)
Offline
Just checked
root: ~ > find /mnt/arch/lib/modules -name "*ext*" -print
/mnt/arch/lib/modules/2.6.32-ARCH/kernel/fs/ext2
/mnt/arch/lib/modules/2.6.32-ARCH/kernel/fs/ext2/ext2.ko
...
So apparently the ext2 driver is built as a module.
I went through
http://wiki.archlinux.org/index.php/Mki … mkinitcpio
but I'm not sure how to handle this without a running Archlinux.
Any hint /wiki on how to use Arch's mkinitcpio from a non-Arch / chroot system?
P.S.
bsdtar -tf /mnt/arch/boot/kernel26.img | grep ext gives me
/lib/modules/2.6.32-ARCH/kernel/fs/ext2
/lib/modules/2.6.32-ARCH/kernel/fs/ext2/ext2.ko
/lib/modules/2.6.32-ARCH/kernel/fs/ext3
/lib/modules/2.6.32-ARCH/kernel/fs/ext3/ext3.ko
Thanks in advance!
Last edited by bunc (2010-01-31 10:01:52)
Offline
You must really like waiting for fsck.
I came from slackware too, and used lilo for the longest time. I switched to grub about 3 months ago, because of not having to regenerate it and the ease of using the grub command line to solve problems at boot time. (I forgot to run lilo after a kernel upgrade, and couldn't find a livecd. Very annoying.)
a)
# /etc/lilo.conf
# Start LILO global section
boot=/dev/sdb2
disk=/dev/sdb bios=0x81
# disk=/dev/hdb bios=0x81 sectors=63 head=255 cylinder=16065
# disk=/dev/hdb bios=0x81
# compact # faster, but won't work on all systems.
default=arch
timeout=180
lba32
prompt
# VESA stuff goes here ..
...
image=/boot/vmlinuz26
label=arch
# root=/dev/disk/by-uuid/e1bb42e5-67c6-40e6-811c-976950c14472
append="root=/dev/sdb2 rootfstype=ext2"
initrd=/boot/kernel26.img
read-only
...
# other OS's
...
How is /dev/sdb2 chainloaded?
What command on slackware are you using to regenerate lilo on /dev/sdb2 with the /etc/lilo.conf that you posted?
Do you boot slackware from the lilo on /dev/sdb2, or from lilo located elsewhere? If you boot slackware from a different lilo, have you tried adding an entry for arch, and booting from there?
What are you trying to accomplish with this?
disk=/dev/sdb bios=0x81
Unless you removed the udev hook from mkinitcpio.conf, referring to / by UUID is preferable, since there can be no confusion. Change your append line to:
append="root=/dev/disk/by-uuid/e1bb42e5-67c6-40e6-811c-976950c14472"
Also, have you tried booting with the fallback image?
Offline
You must really like waiting for fsck.
doesn't harm every now and then - does it?
I switched to grub about 3 months ago, because of not having to regenerate it and the ease of using the grub command line to solve problems at boot time. (I forgot to run lilo after a kernel upgrade, and couldn't find a livecd. Very annoying.)
It's a matter of taste, isn't it? If grub works it's certainly more elegant. But - as opposed to lilo - you sometimes execute grub, let it write to the bootsector, and then end up whith cryptic error messages when rebooting. lilo however, if /sbin/lilo has run thru, will (normally) succeed with finding your kernel and starting the boot process.
After a kernel upgrade I mostly reboot the system immedeately, then run lilo from Slack, dd the bootsector to a directory in my C: drive and let Win bootmgr do his job. This is because I'm under the impression that Arch, after the kernel upgrade, and before a reboot, is in an unstable state and some shell commands will produce funny errors.
How is /dev/sdb2 chainloaded?
Sorry, don't understand that. Isn't "chainload" a grub term, and used for other OS's, like DOS, BSD, ...?
What command on slackware are you using to regenerate lilo on /dev/sdb2 with the /etc/lilo.conf that you posted?
/sbin/lilo. Partition naming is different (hdb versus sdb) otherwise lilo.conf is pretty much the same. I've done this many times berfore (running lilo in Arch, including the Slack install - and vice versa).
Do you boot slackware from the lilo on /dev/sdb2, or from lilo located elsewhere? If you boot slackware from a different lilo, have you tried adding an entry for arch, and booting from there?
If you look on my cfdisk output above, I have Arch on s(h)db2 and Slack on h(s)db7. Both bootsectors are transfered to Windows (whose boot mgr resides in the MBR) with dd.
You might argue this is terribly complicated / unsupported, however I do need Win for my job. Also this has always worked fine no matter if I used the sdb2 (Arch) or the sdb7 (Slack) bootsector. And Slack continues to boot just fine (with both bootsectors, created with either Arch or Slack), and I therein can mount h(s)db2 (Arch root) whith fstype ext2. Arch boot however fails, no matter if I use the lilo bootsector from /dev/sdb2 (created by Arch's lilo) or /dev/hdb7 (created by Slack's lilo).
What are you trying to accomplish with this?
disk=/dev/sdb bios=0x81
hmh, either it came with the distros lilo.conf -template, or I picked it up somewhere in the internet. Don't think it will make a difference, but I shall give it at try. Bios drive no 81 sounds reasonable though, doesn't it.
Unless you removed the udev hook from mkinitcpio.conf, referring to / by UUID is preferable, since there can be no confusion. Change your append line to:
append="root=/dev/disk/by-uuid/e1bb42e5-67c6-40e6-811c-976950c14472"
Good point; you found this line in my lilo.conf and I certainly did try this alternative - before posting.
But maybe it's worth a try if I exchange
UUID=e1bb42e5-67c6-40e6-811c-976950c14472 / ext2 defaults 0 1
with
/dev/sdb2 / ext2 defaults 0 1
in Arch's /etc/fstab
Also, have you tried booting with the fallback image?
Of course I have: same kinit problem as with the regular Arch image.
Last edited by bunc (2010-01-31 20:23:25)
Offline
After a kernel upgrade I mostly reboot the system immedeately, then run lilo from Slack, dd the bootsector to a directory in my C: drive and let Win bootmgr do his job. This is because I'm under the impression that Arch, after the kernel upgrade, and before a reboot, is in an unstable state and some shell commands will produce funny errors.
theapodan wrote:How is /dev/sdb2 chainloaded?
Sorry, don't understand that. Isn't "chainload" a grub term, and used for other OS's, like DOS, BSD, ...?
Chainloading refers to loading one bootmanager from another, like lilo from NTLDR or the newer windows bootmanagers like it sounds like you are doing. You can chainload from lilo too, which is how you can boot windows from lilo.
theapodan wrote:What command on slackware are you using to regenerate lilo on /dev/sdb2 with the /etc/lilo.conf that you posted?
/sbin/lilo. Partition naming is different (hdb versus sdb) otherwise lilo.conf is pretty much the same. I've done this many times berfore (running lilo in Arch, including the Slack install - and vice versa).
If you just run /sbin/lilo in slackware, you won't regenerate the lilo on /dev/sdb2. If you run /sbin/lilo under slackware, it will use the lilo.conf in (slackware)/etc
To regenerate Arch's lilo, you have to pass the arch lilo.conf to (slackware)/sbin/lilo like this:
(slackware)/sbin/lilo -C (arch)/etc/lilo.conf
the arch lilo.conf will have to be edited to conform to the old way of naming ide devices (hdx) since the kernel with Slackware uses the old ide drivers. The root parameter passed to the arch kernel should remain /dev/sdb2, unless you go back to using the UUID, which is better.
The better way to do this is below.
theapodan wrote:Do you boot slackware from the lilo on /dev/sdb2, or from lilo located elsewhere? If you boot slackware from a different lilo, have you tried adding an entry for arch, and booting from there?
And Slack continues to boot just fine (with both bootsectors, created with either Arch or Slack), and I therein can mount h(s)db2 (Arch root) whith fstype ext2. Arch boot however fails, no matter if I use the lilo bootsector from /dev/sdb2 (created by Arch's lilo) or /dev/hdb7 (created by Slack's lilo).
Are you aware that one lilo install can boot both Slackware and Arch?
Mount the arch / partition, and add the following to the slackware lilo.conf:
image=/path_to_arch_root/boot/vmlinuz26
label=arch
append="root=/dev/disk/by-uuid/e1bb42e5-67c6-40e6-811c-976950c14472"
initrd=/path_to_arch_root/boot/kernel26.img
read-only
Run /sbin/lilo in slackware, then copy the slackware bootsector to the windows drive and boot it with the windows bootloader. You can then boot either slackware or arch.
theapodan wrote:What are you trying to accomplish with this?
disk=/dev/sdb bios=0x81hmh, either it came with the distros lilo.conf -template, or I picked it up somewhere in the internet. Don't think it will make a difference, but I shall give it at try. Bios drive no 81 sounds reasonable though, doesn't it.
You don't know what this does, but you have it in lilo.conf?? You should read the lilo.conf manpage if you do not know what something does. You should remove this line.
theapodan wrote:Unless you removed the udev hook from mkinitcpio.conf, referring to / by UUID is preferable, since there can be no confusion. Change your append line to:
append="root=/dev/disk/by-uuid/e1bb42e5-67c6-40e6-811c-976950c14472"Good point; you found this line in my lilo.conf and I certainly did try this alternative - before posting.
But maybe it's worth a try if I exchange
UUID=e1bb42e5-67c6-40e6-811c-976950c14472 / ext2 defaults 0 1
with
/dev/sdb2 / ext2 defaults 0 1
in Arch's /etc/fstab
fstab has no impact on boot until kinit passes control to init. This change will do you no good.
Offline
> Chainloading refers to loading one bootmanager from another, like lilo from NTLDR or the newer windows bootmanagers
> like it sounds like you are doing. You can chainload from lilo too, which is how you can boot windows from lilo.
Yes. And it's also true that grub uses the term "chainload", whereas lilo just calls it "other":
Grub:
title Windows
rootnoverify (hd0,0)
makeactive
chainloader +1
Lilo:
other=/dev/hda1
table=/dev/hda
label=Windows
> If you just run /sbin/lilo in slackware, you won't regenerate the lilo on /dev/sdb2. If you run /sbin/lilo under slackware,
> it will use the lilo.conf in (slackware)/etc
Sure. However the "-C" switch will not work in my case, because Slack(s lilo) doesn't understand /dev/sdb - and Arch(s lilo)
does not understand /dev/hdb.
> Are you aware that one lilo install can boot both Slackware and Arch?
> ...
> Run /sbin/lilo in slackware, then copy the slackware bootsector to the windows drive and boot it with the windows bootloader.
> You can then boot either slackware or arch.
That's precisely what I'm doing. Sorry if I haven't made it clear, although I did mention that I `dd` sdb2 and sdb7 bootsectors,
each of them containing lilo entries for both distros, to the Windows partition:
>> And Slack continues to boot just fine (with both bootsectors, created with either Arch or Slack), and I therein can mount
>> h(s)db2 (Arch root) whith fstype ext2. Arch boot however fails, no matter if I use the lilo bootsector from /dev/sdb2
>> (created by Arch's lilo) or /dev/hdb7 (created by Slack's lilo).
This breaks down to a Win BootMgr which can invoke ("chainload")
1) ntldr
2) boot sector /dev/hdb7: lilo menu Slack with a choice of
a) Slack kernel x
b) Slack kernel y [and maybe more]
c) Arch image
d) Arch fallback image
3) boot sector /dev/sdb2: lilo menu Arch with a choice of
a) Arch image
b) Arch fallback image
c) Slack kernel x
d) Slack kernel y [and maybe more]
I do not want to confuse you even further mentioning that FreeBSD / NetBSD can be started either directly fom Win's
BootMgr or each of the two lilo menues.
> You don't know what this does, but you have it in lilo.conf?? You should read the lilo.conf manpage if you do not
> know what something does. You should remove this line.
I didn't say I don't know what it's good for. I said I wasn't sure if it's essential. According to lilo's manpage it serves
sorting out drive order in case of some braindead old bios's.
> fstab has no impact on boot until kinit passes control to init. This change will do you no good.
Can't harm either, i.e. make things worse than having a non-bootable Arch installation. And it's
as easy as to (un)comment the respective lines in /etc/fstab.
If you look above my error message reads like
kinit: Unable to mount root fs on dev(8,18)
kinit: init not found
and I'm not sure if that's precisely the point in time where kinit reads /etc/fstab, in order to "mount / ro".
This having been said I do not think it makes sense to go into to the pros and cons of lilo, grub, what have you.
As a matter of fact I had a working system, which wouldn't boot anymore after pacman's kernel update - without
having changed anything else in my setup. Should I succeed bringing Arch to live again, I'll certainly keep a
backup copy of a working image and module tree.
Thanks a lot!
Last edited by bunc (2010-02-01 11:51:58)
Offline
i am having an exactly similar problem after the pacman upgrade except tha i am able to log into arch with the arch fallback image...any clue??
Offline
Mount the arch / partition, and add the following to the slackware lilo.conf:
image=/path_to_arch_root/boot/vmlinuz26
label=arch
append="root=/dev/disk/by-uuid/e1bb42e5-67c6-40e6-811c-976950c14472"
initrd=/path_to_arch_root/boot/kernel26.img
read-only
Thanks, theapodan
I was trying to boot to Arch from my Slackware lilo prompt. Your solution worked a treat!
For clarification, an example of "/path_to_arch_root/" would be something like "/mnt/hda2/".
Thanks again.
Last edited by harryhaller (2010-04-09 11:39:59)
Offline
Pages: 1