Anton Aylward composed on 2015-06-25 07:57 (UTC-0400): I don't get why OFF LIST emails are going out set to reply-to-list.
Felix Miata wrote:
Anton Aylward composed on 2015-06-24 21:54 (UTC-0400):
Felix Miata wrote:
no, I don't have dracut for 13.1
If I'm reading things right, the problem isn't going to be solved by drakut. As far as I can tell, drakut is a replacement for mkinitrd.
Technically quite correct. As a practical matter, I'm not so sure. On 13.1 I use either stock kernels, or these: http://download.opensuse.org/repositories/home:/mkubecek:/evergreen-13.1/ope...
Has 13.1 gone evergreen already?
Wiki might still say so. I didn't check lately. Answer is no. That's supposed to happen after current TW morphs into a post-13.2 GA release.
As noted, I use Kernel_stable.
As far as I can tell, mkinitrd is working OK.
Hopefully.
Once we start doubting the fundamentals we're on a downward spiral.
That happened with 12.1, aka systemd.
All I can say is that the various initrds work.
So you're running now on 4.0.5, just bootloader config is broken?
As far as I can tell its is rebuilding /boot/grub2/grub.cfg correctly
IIRC, mkinitrd/dracut on kernel installation/upgrade only trigger bootloader updates, not do them. I think it's perl-Bootloader that calls on the grub/bootloader scripts.
To be honest, I'm not sure that a kernel upgrade SHOULD cause a bootloader update. The thing in the MBR, the stage1/stage2 code of "0.97" or the .mod files of "2' have no reason to change, on the config files that define the menus.
I agree in general. If you aren't booted from rescue media, what's already in MBR and EBR apparently works, sleeping dogs that do not need disturbing. "Bootloader update" can be either or both of two things: 1-binary "installation" or "setup" 2-configuration (boot menuing) Of course, the latter needs changing with every kernel change, unless relying exclusively on symlinks, which most distros including openSUSE do not by default, if ever, attempt to do. On my own installations, normal booting is always via symlinks.
The problem is that grub2 is not doing what I think it should.
I think that's due to bug I gave in previous email.
I've tried doing what *I* think is reinstall grub2 and in the MBR,
I think you somehow failed. What else, other than a bug you and I know nothing about, explains the GRUB halt?
that you YAST, that you command line.
I do not understand your grammar here.
I've described what happens.
I think this is a MBR or whatever problem
Maybe it's both initrd and bootloader. Clearly bootloader is at least part of problem to be dumping you at GRUB.
not a specific mkinitrd/drakut problem.
Were you using kernel-stable before, or were you using 3.11 or 3.12 previously?
I've been using kernel_stable for all of this year. I'm well into the 4.0 series now
# ls -1 /boot/vmlinux* /boot/vmlinux-3.19.3-1.gf10e7fc-default.gz /boot/vmlinux-3.19.3-1.gf10e7fc-desktop.gz /boot/vmlinux-4.0.5-3.gb5e86cc-default.gz /boot/vmlinux-4.0.5-3.gb5e86cc-desktop.gz /boot/vmlinux-4.0.5-4.g56152db-default.gz /boot/vmlinux-4.0.5-4.g56152db-desktop.gz /boot/vmlinux-4.0.5-5.g80f6bcd-default.gz /boot/vmlinux-4.0.5-5.g80f6bcd-desktop.gz /boot/vmlinux-4.1.0-1.gfcf8349-default.gz /boot/vmlinux-4.1.0-1.gfcf8349-desktop.gz
There's a purge_kernels pending.
You actually enabled purge-kernels.service? System installation (YaST/PBL) doesn't do it.
I have
multiversion.kernels = oldest,latest,latest-1,latest-2,running
2 more than default.
Have you looked for mention of mkinitrd or dracut in the kernel-stable changelog or man page?
The changelog has a lot that is irrelevant to me: atuff to do with ARM, modules I don't use like crypto, XEN. The stuff that is relevant is all BtrFS stuff.
IMO, BTRFS is good rationale to upgrade the whole OS, not just kernel, unless you know about and also upgrade everything that touches BTRFS. All I know about BTRFS is it's too new for me to want to touch. It's only been about a year since I started using EXT4 instead of EXT3 on new installations, and then only on 64 bit installations, the far less-used arch here.
mkinitrd is 2.8.1-9.1 and the last changelog entry is Mon 06 Oct 2014 08:00:00 AM EDT.
The grub2 changelogs are 2013/2014.
I suspect kernel-stable sees little service or testing on 13.1. Also, kernel builders are probably all using a much more evolved systemd than that in 13.1, plus newer compiler.
Evidence?
Keyword: suspect. Actual evidence escapes my recollection. It's more about what I don't see than what I do. I keep irc://freenode/#opensuse-factory open, but visit it only at random. There is probably a lot on opensuse-factory mailing list I miss because of skipping many threads based purely on $SUBJECT. I miss even more for that reason and others on kernel, project, yast-devel and packaging lists.
So you are saying 'upgrade to 13.2 cos that's where the real action is'.
I wasn't, though I can understand such an interpretation. IMO, the real action isn't even in TW, but in TW as a foundation, plus widely varying portions of OBS.
Maybe along the way something prudent is, after restoring bootloader menu functionality, booting prior kernel to get latest dracut installed and trying it via cmdline on kernel-stable.
I see no logic in that.
Seeing no logic makes sense, as long as you're fully confident your trouble is exclusively with bootloader.
* I see no reason to start using dracut with 13.1 other than to 'learn about it'
Maybe this is a problem that you and I don't know about.
* I see no reason to worry about 'prior kernels'.
+1 if that's how you've booted since the s*** hit your fan yesterday.
The problem is getting the boot loader to work at all.
It *is* working "at all" now, no? You're getting a grub> prompt and getting kernel and initrd to successfully boot your 13.1 installation, no? If true, this seems to me like the above-referenced bug has caused Grub Legacy to be installed (aka setup) on MBR (and/or PBR???) without any corresponding menu configuration. It needs /boot/grub/menu.lst, not /boot/grub2/grub.cfg. I think you'll find you have both Grub Legacy and Grub2 rpms installed, as is normal even in TW. Here's something else to think about: Anton Aylward composed on 2015-06-24 19:56 (UTC-0400):
This was a 'new' 1T that I partitioned as root & swap are real partitions and a LVM # Start End Size Type Name 1 34 3906250 1.9G BIOS boot parti primary 2 3907584 15624191 5.6G Microsoft basic primary 3 15624192 1953523711 924.1G Linux LVM primary
How did you manage to have such a small (34 sector) boot "track"? Are those 4k sectors being used as 4k sectors? Can your new (from updating) Grub2 core.img with LVM and BTRFS support fit in such a space if what are logically used are 512 bytes? Has its tail managed to roll into your swap partition? Why isn't your swap partition labeled as swap by fdisk, or is it actually an M$ partition? Was GRUB happening because Grub Legacy's MBR sector was installed (due to bug) but does not support 4k? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org