A lesson learnt you can all gain knowledge from

dav7 · 2008-03-15 16:51:54

Note to forum administrators: I think that it would be a good idea to make this thread sticky so more people know about this and don't make the same mistake as me. It's a trivial issue but quite an uncomfortable situation to be in (it was for me anyway).

Hi.

You can skip this bit if you just want the "NEVER DO THIS" part... just scroll down the "The Lesson"

The story
In my interest with the Linux kernel (and qemu's solid refusal to just... work!!!) I became interested in how the kernel functioned. I downloaded a copy of the kernel source, built it and tried to boot it under qemu. It simply wouldn't work. I don't know how to put GRUB on a disk image so was sticking with qemu's -kernel and so on options to use its little internal bootloader. Which wasn't working.

So, I decided to take a different tactic (and one that I now think is the one qemu is designed to work with) and instead of using 'qemu -kernel [..] -hda [..] -append "root=[...]"', use 'qemu -kernel [..] -initrd [..]', which would very likely work. So I thought, "how do initrd images work?", and after finding no real info on how it all went together, "how do you look inside an initrd image?"

So a quick learn (where from I forget) and a google turned up how to use cpio to extract Arch Linux' initrd/initramfs image. The particular cpio syntax used extracted everything into the exact same places they were before, and I happened to be root at the time, so suddenly every - EVERY - binary in the initrd had replaced those in my filesystem.

Oops.

After pacman -S'ing every package already installed (took 3 hours) I then fought some odd kernel issues, rebuilt the kernel initramfs image with PATA support (after quite a long "session" with everyone on #archlinux@freenode (IRC) - they just kept fooling around, referring me to URLs and manpages when I was stressed out and needed plain old commands to run, then someone just went and gave me the command to rebuild the initramfs image), and suddenly had a bootable, working system.

Or did I?

So here I am, with my "working" system, I need to put my PC back together (I'd taken it apart during the "broken PC" stage) and so I run poweroff to turn it off. The system turns off instantly without any shutdown scripts being run.

"?!?!?!?! wait a second......."

As you know, poweroff is designed to run a few shutdown scripts to unmount mounted disks, stop the network, stop running services, etc. Well, those scripts weren't being run, even though #1 the scripts existed on my system and #2 /sbin/halt had the same md5sum as the same binary on another system of mine. I never did figure out why poweroff was broken (very likely some script that was being run instead of the one that was supposed to be run) and in the end I had to reinstall. I backed up the old installation though. xD

As a last "interesting note", when I ran halt or poweoff as non-superuser I was getting "failed." instead of "/sbin/poweroff: must be superuser.".

The Lesson
* NEVER RUN A COMMAND YOU DON'T KNOW THE OUTCOME OF AS ROOT. That would have to be the best piece of advice.
* cpio, when run without the --no-absolute-filenames option will extract the contents of an initramfs image over a root filesystem if given the chance.

I hope something has been learnt from this by the reader.

-dav7

Last edited by dav7 (2008-03-15 16:52:43)

MoonSwan · 2008-03-15 22:30:29

I learned that if you ever tell me to run xyz command as root that I should run, instead, as far away as possible.

dav7 · 2008-03-17 15:07:48

MoonSwan wrote:

I learned that if you ever tell me to run xyz command as root that I should run, instead, as far away as possible.

Aww! But rm -rf / is good! It compresses your filesystem by 100%!

shining · 2008-03-17 16:07:17

dav7 wrote:

The Lesson
* NEVER RUN A COMMAND YOU DON'T KNOW THE OUTCOME OF AS ROOT. That would have to be the best piece of advice.
* cpio, when run without the --no-absolute-filenames option will extract the contents of an initramfs image over a root filesystem if given the chance.

You forgot one :
* READ THE WIKI

( http://wiki.archlinux.org/index.php/Con … r_the_hood )

zodmaner · 2008-03-17 17:06:52

Yeah, reading the wiki is the most foolproof way to prevent you from committing simple mistake or blunder.
+1 for the Arch wiki.

Last edited by zodmaner (2008-03-17 17:09:37)

dav7 · 2008-03-18 01:59:15

Well, the wiki is nice, but... well... the wiki is static information that will not context-switch.

"huh?!"

If you create a wiki entry entitled "partition structures explained" and don't use the words "hard", "disk" or "editing" anywhere in your text (for the sake of argument) then I search the wiki for "hard disk editing", your entry would be a no show in the article listing.

However, if content context-switched algorithimagintellically (*ahem*), the wiki would return your article in the listing.

My point? I dislike searching for stuff because I almost always don't use the right words - or more accurately, the same words as everyone else, so searching is often a hunt-and-peck game for me.

-dav7

PS: I R LEET - look at the edit time

Last edited by dav7 (2008-03-18 02:07:14)

Misfit138 · 2008-03-18 02:25:47

Try the table of contents.

Arch Linux

#1 2008-03-15 16:51:54

A lesson learnt you can all gain knowledge from

#2 2008-03-15 22:30:29

Re: A lesson learnt you can all gain knowledge from

#3 2008-03-17 15:07:48

Re: A lesson learnt you can all gain knowledge from

#4 2008-03-17 16:07:17

Re: A lesson learnt you can all gain knowledge from

#5 2008-03-17 17:06:52

Re: A lesson learnt you can all gain knowledge from

#6 2008-03-18 01:59:15

Re: A lesson learnt you can all gain knowledge from

#7 2008-03-18 02:25:47

Re: A lesson learnt you can all gain knowledge from

Board footer