Reinstall of CoreOS after adding disk bombs
by Shivaram Mysore
Hello,
I used mmcblk0 as the initial boot disk and was able to get coreos
installed and fully operational. I then added a disk sda. I reinstalled
(via PXE - fully wipe) coreos on mmcblk0
Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or
/boot
after mounting them and attach it to a bug report.
possible culprit segment: (attached full report)
0m] Started dracut initqueue hook.
[ 19.087502] audit: type=1130 audit(1569089886.588:10): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=kernel msg='unit=dracut-initqueue
comm="systemd'
[ 19.087975] systemd[1]: Reached target Remote File Systems (Pre).
[ OK ] Reached target Remote File Systems (Pre).
[ OK 19.122542] systemd[1]: Reached target Remote File Systems.
0m] Reached target Remote File Systems.
[ 19.139331] systemd[1]: Starting dracut pre-mount hook...
Starting dracut pre-mount hook...
[ 19.187689] systemd[1]: Started dracut pre-mount hook.
[ OK ] Started dracut pre-mount hook.
[ 19.201538] audit: type=1130 audit(1569089886.702:11): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=kernel msg='unit=dracut-pre-mount
comm="systemd'
[ 19.204533] systemd[1]: Starting File System Check on
/dev/disk/by-label/root...
Starting File System Check on /dev/disk/by-label/root...
[ 19.260857] systemd-fsck[863]: /usr/sbin/fsck.xfs: XFS file system.
[ OK 19.270410] systemd[1]: Started File System Check on
/dev/disk/by-label/root.
0m] Started File System Check on /dev/disk/by-label/root.
[ 19.291614] systemd[1]: Mounting /sysroot...
Mountin[ 19.296078] audit: type=1130 audit(1569089886.789:12):
pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel
msg='unit=systemd-fsck-r'
g /sysroot...
[ 19.771792] SGI XFS with ACLs, security attributes, scrub, no debug
enabled
[ 19.788579] XFS (sda4): Mounting V5 Filesystem
[ 19.813813] XFS (sda4): Ending clean mount
[ OK 20.125540] systemd[1]: Mounted /sysroot.
0m] Mounted /sysroot.
[ 20.137017] systemd[1]: Condition check resulted in Remount /sysroot
read-write for Ignition being skipped.
Startin[ 20.147072] systemd[1]: Starting OSTree Prepare OS/...
g OSTree Prepare OS/ 20.155340] ostree-prepare-root[885]:
ostree-prepare-root: Couldn't find specified OSTree root
'/sysroot//ostree/boot.1/fedora-corey
m...
[ 19.202077] ostree-prepare-root[885]: ostree-prepare-root: Couldn't find
specified OSTree root
'/sysroot//ostree/boot.1/fedora-coreos/b2601a3ea2062ef1y
[FAILED[ 20.201741] systemd[1]: ostree-prepare-root.service: Main process
exited, code=exited, status=1/FAILURE
] Failed to [ 20.212566] systemd[1]: ostree-prepare-root.service: Failed
with result 'exit-code'.
start O[ 20.221776] systemd[1]: Failed to start OSTree Prepare OS/.
STree Prepare OS/
Let me know if you need any other info
3 years, 8 months
Re: Fedora coreos-assembler (enabling kvm option)
by Andrew Jeddeloh
When I was testing on the packet c2.arm instances I didn't hit any
issues, it pretty much "just worked".
On Wed, Sep 25, 2019 at 1:56 PM Ed Vielmetti <ed(a)packet.com> wrote:
>
> How well do things work when you build arm64 images native on arm64?
>
> On Wed, Sep 25, 2019 at 12:55 PM Andrew Jeddeloh <andrew.jeddeloh(a)redhat.com> wrote:
>>
>> I can confirm that /dev/kvm is a requirement to build images.
>>
>> - Andrew
>>
>> On Wed, Sep 25, 2019 at 1:07 AM Sinny Kumari <ksinny(a)gmail.com> wrote:
>> >
>> > Hi Madhurika,
>> >
>> > CC'ing coreos-devel so that other folks can chime in case I missed something
>> >
>> > On Wed, Sep 25, 2019 at 2:10 AM Madhurika Joshi <mjoshi2(a)marvell.com> wrote:
>> >>
>> >> Hello Sinny,
>> >>
>> >>
>> >>
>> >> Hope you are doing well.
>> >>
>> >>
>> >>
>> >> I am working with the coreos-assembler and I had a question regarding the same.
>> >
>> >
>> > Thanks for reaching out to me, nice to see that you are trying out coreos-assembler :)
>> >
>> >> My host OS is x86 and I have a ubuntu server (arm64) installed on QEMU. I built the cosa container image locally on qemu using the dockerfile and now I am trying to generate the VM images (arm64) following the steps mentioned in the readme (cosa init, cosa fetch and cosa build). But the cosa project however has a pre-req that it needs access to virtualization /dev/kvm.
>> >
>> >
>> > I haven't personally tried running cosa in a cross architecture VM, so not sure about how well it works. Just making sure, is nested virt enabled on your host machine?
>> >
>> >
>> >>
>> >> However in my case, since my host and guest architecture are different I cannot use KVM on QEMU and therefore cannot use it within the container. Is there a way to disable the KVM option? If yes, can you guide me a little to understand how this can be done.
>> >
>> >
>> > I believe access to /dev/kvm is necessary in order to build images, for example see https://github.com/coreos/coreos-assembler/blob/master/src/cmdlib.sh#L392 which is invoked during image build https://github.com/coreos/coreos-assembler/blob/master/src/cmd-buildexten...
>> >
>> >>
>> >> Looking forward to hearing back from you.
>> >>
>> >>
>> >>
>> >> Thanks and Regards,
>> >>
>> >> Madhurika Joshi
>> >
>> >
>> >
>> > --
>> > http://sinny.io/
>> > _______________________________________________
>> > CoreOS mailing list -- coreos(a)lists.fedoraproject.org
>> > To unsubscribe send an email to coreos-leave(a)lists.fedoraproject.org
>> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives: https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org
>> _______________________________________________
>> CoreOS mailing list -- coreos(a)lists.fedoraproject.org
>> To unsubscribe send an email to coreos-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org
3 years, 8 months
Questions on FCOS Internals
by John Osborne
Hi SMEs,
Iv'e been using Fedora CoreOS (FCOS) and I had some questions. Any help
would be greatly appreciated, thank you!
Q: Is there a way to pass FCOS an ignition file while it's running for the
next reboot? Or do you need to externally kill the machine and pass the
.ign file again through the firmware?
Q: Can you see the ignition file while the machine is running that was
passed during startup? Is it unmounted somewhere or in the initramfs.img
file?
Q: It looks like I can turn on automatic updates on FCOS by editing
/etc/rpm-ostreed.conf. Will that make my machine auto-reboot? When?
Q: How do rpm-ostree and ignition work together? Does rpm-ostree pull down
ostree updates on some sort of cronjob type schedule? Are the updates in an
OCI image (oscontainer)? Where is the image unpacked? How does ignition
know which image to use when it starts the machine?
--
John Osborne
CHIEF openshift architect, RHCE
Red Hat Public Sector <https://www.redhat.com>
josborne(a)redhat.com M: 7037721090
<https://red.ht/sig>
3 years, 8 months
Fedora CoreOS Meeting Minutes 2019-09-25
by Dusty Mabe
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-25/fedora_core...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-25/fedora_core...
Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-25/fedora_core...
========================================
#fedora-meeting-1: fedora_coreos_meeting
========================================
Meeting started by dustymabe at 16:30:01 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-25/fedora_core...
.
Meeting summary
---------------
* roll call (dustymabe, 16:30:06)
* Action items from last meeting (dustymabe, 16:34:29)
* FCOS as Kubernetes / OKD node (dustymabe, 16:35:35)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/93
(dustymabe, 16:35:41)
* strigazi will trying using podman to replace atomic CLI for system
containers to run the kubelet for Openstack Magnum (dustymabe,
16:48:07)
* Set up annex OSTree repo (dustymabe, 17:08:20)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/266
(dustymabe, 17:08:27)
* please add your votes to the proposal in the ticket:
https://github.com/coreos/fedora-coreos-tracker/issues/266#issuecomment-5...
(dustymabe, 17:08:48)
* python3 getting pulled in by crypto-policies (dustymabe, 17:13:38)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/280
(dustymabe, 17:13:43)
* ACTION: ajeddeloh to investigate the addition of python in
update-crypto-policies #280 (dustymabe, 17:27:47)
* open floor (dustymabe, 17:29:50)
Meeting ended at 17:33:32 UTC.
Action Items
------------
* ajeddeloh to investigate the addition of python in
update-crypto-policies #280
Action Items, by person
-----------------------
* ajeddeloh
* ajeddeloh to investigate the addition of python in
update-crypto-policies #280
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* dustymabe (97)
* lorbus (38)
* bgilbert (29)
* ajeddeloh (20)
* zodbot (19)
* strigazi (18)
* red_beard (17)
* jlebon (9)
* kaeso[m] (7)
* slowrie (3)
* jdoss (2)
* brtknr (1)
* geoff- (1)
* walters (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
3 years, 8 months
Re: Fedora coreos-assembler (enabling kvm option)
by Sinny Kumari
Hi Madhurika,
CC'ing coreos-devel so that other folks can chime in case I missed something
On Wed, Sep 25, 2019 at 2:10 AM Madhurika Joshi <mjoshi2(a)marvell.com> wrote:
> Hello Sinny,
>
>
>
> Hope you are doing well.
>
>
>
> I am working with the coreos-assembler and I had a question regarding the
> same.
>
Thanks for reaching out to me, nice to see that you are trying out
coreos-assembler :)
My host OS is x86 and I have a ubuntu server (arm64) installed on QEMU. I
> built the cosa container image locally on qemu using the dockerfile and now
> I am trying to generate the VM images (arm64) following the steps mentioned
> in the readme (cosa init, cosa fetch and cosa build). But the cosa project
> however has a pre-req that it needs access to virtualization /dev/kvm.
>
I haven't personally tried running cosa in a cross architecture VM, so not
sure about how well it works. Just making sure, is nested virt enabled on
your host machine?
> However in my case, since my host and guest architecture are different I
> cannot use KVM on QEMU and therefore cannot use it within the container. Is
> there a way to disable the KVM option? If yes, can you guide me a little to
> understand how this can be done.
>
I believe access to /dev/kvm is necessary in order to build images, for
example see
https://github.com/coreos/coreos-assembler/blob/master/src/cmdlib.sh#L392
which is invoked during image build
https://github.com/coreos/coreos-assembler/blob/master/src/cmd-buildexten...
> Looking forward to hearing back from you.
>
>
>
> Thanks and Regards,
>
> Madhurika Joshi
>
--
http://sinny.io/
3 years, 8 months
Network configuration issues
by Shivaram Mysore
Hello,
I have a box with multiple network interfaces. I am running:
# *uname -a*
Linux rhino 5.2.11-200.fc30.x86_64 #1 SMP Thu Aug 29 12:43:20 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
# *cat /etc/*release*
Fedora release 30 (Thirty)
NAME=Fedora
VERSION="30.20190905.0 (CoreOS preview)"
ID=fedora
VERSION_ID=30
VERSION_CODENAME=""
PLATFORM_ID="platform:f30"
PRETTY_NAME="Fedora 30.20190905.0 (CoreOS preview)"
I am happy with eth0 as it uses DHCP.
What is the best way to configure on the system the below command:
$ *sudo ifconfig eth1 0*
I have a container in which I have an interface - call it a OVS bridge
which will be linked to eth1 and that interface will get the IP address. I
also need to force the container to use eth1 as the default route interface
and not eth0.
I understand that Network Manager (/var/run/NetworkManager/) is the method
to configure networking on this CoreOS. Is this model supported? Any
references to how this can be accomplished?
I have another similar use case for a VPN tunnel.
Appreciate pointers.
Thanks & Regards
/Shivaram
3 years, 8 months
Re: EC2 access for testing?
by Geoffrey Marr
I have been using Amazon's "Free Tier" cloud machines to test EC2 images
since 2016. Anyone with an Amazon account (which is free) can spin up a
"free tier" machine to run the tests on. With access so easy, is it
Fedora's job to provide users/testers with an account with which to test
these images?
Geoff Marr
IRC: coremodule
On Fri, Sep 13, 2019 at 3:18 PM Paul Frields <pfrields(a)redhat.com> wrote:
> Actually, I'd prefer we not expand use of that second "community-cloud"
> account, Dusty. Especially since we seem to be in an uncertain state for it
> pretty much constantly as our friends at AWS try to work out how to get it
> into their community umbrella.
>
> Instead, Adam should make use of the existing Fedora AWS account where we
> can delegate access via IAM and using roles. Check in with the infra team
> -- they can follow an SOP
> <https://docs.pagure.org/infra-docs/sysadmin-guide/sops/aws-access.html>
> to make roles, but you'll still need to work with them to tag some
> resources and set up a policy so you can play in the right sandbox.
>
> --
>
> Paul W. Frields
>
> He / Him / His
>
> Sr. Engineering Manager, Platform - Red Hat <https://www.redhat.com/>
>
> 314 Littleton Rd, Westford, MA 01886
>
> pfrields(a)redhat.com / T: 9783921014 / GPG ID: 0xBD113717
> <https://www.redhat.com/>
>
>
> On Fri, Sep 13, 2019 at 4:56 PM Dusty Mabe <dusty(a)dustymabe.com> wrote:
>
>>
>>
>> On 9/13/19 4:51 PM, Adam Williamson wrote:
>> > On Fri, 2019-09-13 at 16:25 -0400, Dusty Mabe wrote:
>> >>
>> >> On 9/13/19 3:44 PM, Adam Williamson wrote:
>> >>> Hi folks! We're currently still discussing adjusting the release
>> >>> criteria to explicitly require Fedora releases to boot in EC2. Someone
>> >>> pointed out that if we're going to require that, it would be good if
>> we
>> >>> had an account allowing EC2 access for testing, so individual Fedora
>> >>> testers don't have to potentially pay out-of-pocket just to test
>> Fedora
>> >>> works in EC2. Does anyone know if we have an existing arrangement with
>> >>> Amazon for this? Thanks!
>> >>>
>> >>
>> >> cc Paul Frields
>> >>
>> >> I have access to an account I think we use explicitly for testing
>> Fedora in AWS.
>> >> Adam, if Paul doesn't point out any reason not to I can hand you some
>> credentials.
>> >
>> > It'd be better for it to be something more robust and 'team-accessible'
>> > than just people emailing each other passwords, ideally :)
>> >
>> Encrypted of course :-P
>>
>> It would be better to have it be something more managed but I don't have
>> anything
>> more robust that I can offer right now. Maybe fedora infra does.
>>
>> Dusty
>>
> _______________________________________________
> cloud mailing list -- cloud(a)lists.fedoraproject.org
> To unsubscribe send an email to cloud-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
>
3 years, 8 months
Fedora CoreOS Meeting Minutes 2019-09-18
by Dusty Mabe
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/fedora_core...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/fedora_core...
Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/fedora_core...
========================================
#fedora-meeting-1: fedora_coreos_meeting
========================================
Meeting started by dustymabe at 16:30:30 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/fedora_core...
.
Meeting summary
---------------
* roll call (dustymabe, 16:30:35)
* Action items from last meeting (dustymabe, 16:34:02)
* bgilbert added ` Immutable root directory (#270)` to the list of
items to document in #159 (dustymabe, 16:35:16)
* Ignition: Support multi part mime for user-data (dustymabe, 16:36:15)
* LINK: https://github.com/coreos/ignition/issues/849 (dustymabe,
16:36:24)
* AGREED: to support the openstack heat use case we can make ignition
support multi-part mime user-data on the openstack platform only.
discussion will continue in the ticket on how targeted to heat the
support will be (dustymabe, 17:13:35)
* coreos/toolbox v2 (dustymabe, 17:13:49)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/38
(dustymabe, 17:13:55)
* toolbox future direction discussion ticket:
https://github.com/debarshiray/toolbox/issues/265 (dustymabe,
17:15:47)
* AGREED: regarding golang vs rust that is up to the author of
toolbox. we do care about size and exploding the number of
container-runtime implementations. If Golang is chosen we prefer
that we don't vendor libpod, but rather either shell out or use the
varlink API to manage containers. (dustymabe, 17:33:38)
* open floor (dustymabe, 17:33:47)
* LINK: https://github.com/coreos/mantle/pull/1046 merge me! (jdoss,
17:34:00)
Meeting ended at 17:34:42 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* dustymabe (112)
* bgilbert (47)
* strigazi (29)
* rishi (21)
* zodbot (21)
* ajeddeloh (17)
* kaeso[m] (8)
* red_beard (8)
* jdoss (4)
* mheon (4)
* jlebon (3)
* slowrie (2)
* mnguyen_ (1)
* ksinny (1)
* walters (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
3 years, 8 months