[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: Probably silly Q about bootable partitions
From:       Gene Heskett <gheskett () wdtv ! com>
Date:       2013-12-31 22:12:04
Message-ID: 201312311712.04217.gheskett () wdtv ! com
[Download RAW message or body]

On Tuesday 31 December 2013, Gene Heskett wrote:
>On Tuesday 31 December 2013, Roger Heflin wrote:
>>rescue boot it, change the /boot mount line in /etc/fstab to add
>>noauto (like noauto,defaults...or whatever else you already have) and
>>change the last column to 0 to disable fsck on it.
>>
>>It should boot then, and you have the machine fully up were you can do
>>better debugging.
>
>It did not, reports a runaway loop in modprobe binfmt-464c, then spits
>out a panic report mentioning the kernel command line option of init= &
>freezes with that report still on screen.
>
>In this install, grub does a preliminary modprobe ext2, but the /boot is
>ext2-3.  And has been for several years.
>
>More clues?
>
>Thanks.
>
>>ie mount /boot may give you a useful error, or it may work...if it
>>works that implies that in the initrd some piece needed to start /boot
>>is not there (fs mayb?).
>>
>>/boot is only needed by the bios...it is not needed when the os is up
>>except to update teh booting kernel to a new one...
>>
>>On Tue, Dec 31, 2013 at 12:05 PM, Gene Heskett <gheskett@wdtv.com> wrote:
>>> Greetings;
>>> 
>>> I can't build a bootable 3.12.6 kernel, it seems to die quite fast
>>> with a trace blaming binfmt-some-hex-number.  Or fail well into the
>>> boot waiting for / to come available.  But if I choose a shell at
>>> that failure, it isn't / that is not shown in a blkid report, it is
>>> /boot, named "ububoot" thats missing. "/", named uburoot, is fine.
>>> 
>>> Here is blkid output booted to 3.12.0.
>>> 
>>> gene@coyote:~/src/linux-3.12.6$ blkid
>>> /dev/sdc1: UUID="1321fc90-ba7a-4742-8176-f7b3a8284be5" TYPE="ext4"
>>> /dev/sdc2: LABEL="amandatapes-1-T"
>>> UUID="b7657920-d9a2-4379-ae21-08a0651b65cc" SEC_TYPE="ext2"
>>> TYPE="ext3" /dev/sda1: LABEL="ububoot"
>>> UUID="f54ba7af-1545-43f3-a86e-bfc0017b4526" SEC_TYPE="ext2"
>>> TYPE="ext3" /dev/sda2: LABEL="uburoot"
>>> UUID="ec677e9c-6be6-4311-b97b-3889d42ce6ef" TYPE="ext4" /dev/sda3:
>>> UUID="edc2880e-257d-4521-8220-0df5b57dcae4" TYPE="swap" /dev/sdb1:
>>> UUID="80ab0463-d6fc-4f5b-af08-5aa43d55fdf8" SEC_TYPE="ext2"
>>> TYPE="ext3" /dev/sdb5: UUID="b4841721-a040-48bc-80dc-e742164ad38a"
>>> TYPE="swap" /dev/sdd1: LABEL="home2"
>>> UUID="7601432d-7a30-42a3-80b5-57f08ae71f2a" TYPE="ext4" /dev/sdd2:
>>> LABEL="opt2" UUID="748b01e1-ae7b-4b17-b8e9-c88429bcefbf" TYPE="ext4"
>>> 
>>> Duplicating this 3.12.0's settings under "filesystems" for 3.12.6 is
>>> apparently not the needed fix.
>>> 
>>> Clues for the apparently clueless?

NEW PS: As it turned out, 3.12.0 the version booted as I am working on 
this, was not mounting it, so I was writing all my new boot file attempts 
to the directory UNDER the mount point.  So I changed /etc/fstab to use the 
partition LABEL to mount it, and I can mount and umount it at will with no 
errors.  I've no clue, the UUID looked good, but it obviously wasn't 
working, so now my script is trying to write another boot build, about the 
20th over the last 2-3 days.

INMNSHO, if it fails to mount /boot as a separate partition, it should stop 
and bitch about it in plain English (or whatever the locale setting is at 
compile time) right then and there.

How do I go about doing an update to a clone of linux-stable?, I would like 
to bisect that in a bit more detail, but linux-stable will not do a git 
checkout v3.12.6, I assume because its now 3 or so days old a clone.

Or, should I switch to the Linus tree?

There is also to possibility that my fstab fixes have fixed this, I'll know 
in 15 minutes.

Yes, the boot worked this time.  I even have audio, but the amp I bought 
yesterday needs another 30 db of gain, its just a whisper.  Not a linux 
problem, it also wasn't very loud when I tested it with a small cd player.

Anyway, thanks for listening/reading this far.

Cheers, Gene

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[prev in list] [next in list] [prev in thread] [next in thread]