Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #257358 > unrolled thread
| Started by | Default User <hunguponcontent@gmail.com> |
|---|---|
| First post | 2023-04-18 17:00 +0200 |
| Last post | 2023-04-19 22:40 +0200 |
| Articles | 20 on this page of 81 — 19 participants |
Back to article view | Back to linux.debian.user
/etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-18 17:00 +0200
Re: /etc/fstab question (problem)? Charles Curley <charlescurley@charlescurley.com> - 2023-04-18 17:40 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-18 19:00 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-18 21:10 +0200
Re: /etc/fstab question (problem)? Tom Furie <tom@furie.org.uk> - 2023-04-18 23:20 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-19 06:40 +0200
tmp on tmpfs Max Nikulin <manikulin@gmail.com> - 2023-04-19 08:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-19 08:40 +0200
Re: tmp on tmpfs Nicolas George <george@nsup.org> - 2023-04-19 09:00 +0200
Re: tmp on tmpfs tomas@tuxteam.de - 2023-04-19 10:00 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 18:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-24 19:10 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 19:40 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 18:20 +0200
Re: tmp on tmpfs Max Nikulin <manikulin@gmail.com> - 2023-04-19 13:10 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-19 20:10 +0200
Re: tmp on tmpfs songbird <songbird@anthive.com> - 2023-04-20 15:00 +0200
Re: tmp on tmpfs Vincent Lefevre <vincent@vinc17.net> - 2023-04-20 16:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-20 16:30 +0200
Re: tmp on tmpfs Vincent Lefevre <vincent@vinc17.net> - 2023-04-20 17:20 +0200
Re: tmp on tmpfs Jeffrey Walton <noloader@gmail.com> - 2023-04-20 16:30 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-20 16:40 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-18 18:00 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-18 22:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-18 23:50 +0200
Re: /etc/fstab question (problem)? Greg Wooledge <greg@wooledge.org> - 2023-04-19 00:00 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 02:00 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 03:20 +0200
Re: /etc/fstab question (problem)? Charles Curley <charlescurley@charlescurley.com> - 2023-04-19 04:50 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 05:00 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 05:10 +0200
Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-19 05:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 11:20 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-19 13:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 22:10 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:00 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:10 +0200
Re: /etc/fstab question (problem)? davidson <davidson@freevolt.org> - 2023-04-20 01:50 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 03:50 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:10 +0200
Re: /etc/fstab question (problem)? rhkramer@gmail.com - 2023-04-21 11:10 +0200
Re: /etc/fstab question (problem)? Greg Wooledge <greg@wooledge.org> - 2023-04-21 13:20 +0200
gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:00 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-20 15:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 20:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-20 22:10 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 00:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Jeremy Ardley <jeremy@ardley.org> - 2023-04-21 01:10 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 19:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Jeremy Ardley <jeremy@ardley.org> - 2023-04-20 15:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-20 17:30 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 20:30 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-22 08:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 22:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 00:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-21 04:40 +0200
Re: /etc/fstab question (problem)? Dan Ritter <dsr@randomstring.org> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 23:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:30 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 00:10 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 00:20 +0200
[SOLVED] Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 02:30 +0200
Re: [SOLVED] Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 03:00 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-21 17:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-22 00:50 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-22 17:30 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-23 04:00 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-23 06:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-23 10:20 +0200
Re: /etc/fstab question (problem)? Celejar <celejar@gmail.com> - 2023-04-24 18:30 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-25 15:00 +0200
old memory sticks (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-23 17:20 +0200
[SOLVED]: old memory sticks songbird <songbird@anthive.com> - 2023-04-24 03:50 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:10 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-20 17:20 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-21 06:30 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-21 06:50 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 16:30 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 22:40 +0200
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-20 00:10 +0200 |
| Message-ID | <Gmo9X-3ad8-5@gated-at.bofh.it> |
| In reply to | #257410 |
On 4/19/23 14:26, Default User wrote: > On Wed, 2023-04-19 at 14:03 -0700, David Christensen wrote: >> On 4/19/23 13:06, Default User wrote: >>> On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote: >>>> Perhaps update-initramfs is necessary after restoring of >>>> /etc/fstab >>>> in >>>> any chosen approach. >> But, I cannot address Max's point about initrd(4). >> >> >> At this point, I would run my daily backups, use an editor to put the >> original /etc entry back into /etc/fstab, forget about messing with >> /etc >> on either file system, and reboot. After reboot, I would run 'df >> /etc' >> and check where /etc is mounted. If /etc is "Mounted on /", I would >> run >> update-initramfs(8), reboot, and look again. > I'm afraid I don't quit understand why 'If /etc is "Mounted on /", I > would run update-initramfs(8), reboot, and look again." > > > Shouldn't etc always be expected to be mounted under /, as in /etc? > For example, right now on my computer: > > df /etc > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/nvme0n1p2 23854928 5841492 16776344 26% / /etc is a subdirectory of the / directory on the Unix "one big file system". Some file system must be mounted at /. Additional file systems must be mounted somewhere beneath /. Where they are mounted is call the "mountpoint". Mountpoints are traditionally subdirectories, and traditionally empty. When a file system is mounted there, the root of that file system is visible as the contents of the mountpoint. On my system, the virtual device /dev/mapper/sda4_crypt has a mount point of /. That file system contains a directory /etc. So, in the Unix "one big file system", the directories / and /etc both come from the file system on /dev/mapper/sda4_crypt. 2023-04-19 14:38:19 root@taz ~ # df / /etc Filesystem 1M-blocks Used Available Use% Mounted on /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / AIUI you want the file system on the the partition /dev/nvme0n1p5 to be mounted at /tmp. The way to do that is to put the relevant entry back into /etc/fstab: UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2 And then reboot. > And, would there be anything wrong with, either way, running update- > initramfs? > > Would that be run as: > > sudo update-initramfs -uv > > ? Unfortunately, more confusion -- there are two Linux "Initial ramdisk" solutions with very similar names -- initrd and initramfs. Forget about those for now. I would add the /etc entry back into /etc/fstab, reboot, run 'df / /etc', and see what happens. David
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-20 00:20 +0200 |
| Message-ID | <GmojD-3ags-1@gated-at.bofh.it> |
| In reply to | #257411 |
On 4/19/23 15:03, David Christensen wrote: > On 4/19/23 14:26, Default User wrote: >> On Wed, 2023-04-19 at 14:03 -0700, David Christensen wrote: >>> On 4/19/23 13:06, Default User wrote: >>>> On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote: > >>>>> Perhaps update-initramfs is necessary after restoring of >>>>> /etc/fstab >>>>> in >>>>> any chosen approach. > >>> But, I cannot address Max's point about initrd(4). >>> >>> >>> At this point, I would run my daily backups, use an editor to put the >>> original /etc entry back into /etc/fstab, forget about messing with >>> /etc >>> on either file system, and reboot. After reboot, I would run 'df >>> /etc' >>> and check where /etc is mounted. If /etc is "Mounted on /", I would >>> run >>> update-initramfs(8), reboot, and look again. > >> I'm afraid I don't quit understand why 'If /etc is "Mounted on /", I >> would run update-initramfs(8), reboot, and look again." >> >> >> Shouldn't etc always be expected to be mounted under /, as in /etc? >> For example, right now on my computer: >> >> df /etc >> Filesystem 1K-blocks Used Available Use% Mounted on >> /dev/nvme0n1p2 23854928 5841492 16776344 26% / > > > /etc is a subdirectory of the / directory on the Unix "one big file > system". > > > Some file system must be mounted at /. > > > Additional file systems must be mounted somewhere beneath /. Where they > are mounted is call the "mountpoint". Mountpoints are traditionally > subdirectories, and traditionally empty. When a file system is mounted > there, the root of that file system is visible as the contents of the > mountpoint. > > > On my system, the virtual device /dev/mapper/sda4_crypt has a mount > point of /. That file system contains a directory /etc. So, in the > Unix "one big file system", the directories / and /etc both come from > the file system on /dev/mapper/sda4_crypt. > > 2023-04-19 14:38:19 root@taz ~ > # df / /etc > Filesystem 1M-blocks Used Available Use% Mounted on > /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / > /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / > > > AIUI you want the file system on the the partition /dev/nvme0n1p5 to be > mounted at /tmp. The way to do that is to put the relevant entry back > into /etc/fstab: > > UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2 > > And then reboot. > > >> And, would there be anything wrong with, either way, running update- >> initramfs? >> >> Would that be run as: >> >> sudo update-initramfs -uv >> >> ? > > > Unfortunately, more confusion -- there are two Linux "Initial ramdisk" > solutions with very similar names -- initrd and initramfs. Forget about > those for now. > > > I would add the /etc entry back into /etc/fstab, reboot, run 'df / > /etc', and see what happens. Correction: add the /tmp entry back into /etc/fstab > > > David >
[toc] | [prev] | [next] | [standalone]
| From | Default User <hunguponcontent@gmail.com> |
|---|---|
| Date | 2023-04-20 02:30 +0200 |
| Subject | [SOLVED] Re: /etc/fstab question (problem)? |
| Message-ID | <Gmqlr-3bss-1@gated-at.bofh.it> |
| In reply to | #257412 |
On Wed, 2023-04-19 at 15:09 -0700, David Christensen wrote: > On 4/19/23 15:03, David Christensen wrote: > > On 4/19/23 14:26, Default User wrote: > > > On Wed, 2023-04-19 at 14:03 -0700, David Christensen wrote: > > > > On 4/19/23 13:06, Default User wrote: > > > > > On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote: > > > > > > > > Perhaps update-initramfs is necessary after restoring of > > > > > > /etc/fstab > > > > > > in > > > > > > any chosen approach. > > > > > > But, I cannot address Max's point about initrd(4). > > > > > > > > > > > > At this point, I would run my daily backups, use an editor to > > > > put the > > > > original /etc entry back into /etc/fstab, forget about messing > > > > with > > > > /etc > > > > on either file system, and reboot. After reboot, I would run > > > > 'df > > > > /etc' > > > > and check where /etc is mounted. If /etc is "Mounted on /", I > > > > would > > > > run > > > > update-initramfs(8), reboot, and look again. > > > > > I'm afraid I don't quit understand why 'If /etc is "Mounted on > > > /", I > > > would run update-initramfs(8), reboot, and look again." > > > > > > > > > Shouldn't etc always be expected to be mounted under /, as in > > > /etc? > > > For example, right now on my computer: > > > > > > df /etc > > > Filesystem 1K-blocks Used Available Use% Mounted on > > > /dev/nvme0n1p2 23854928 5841492 16776344 26% / > > > > > > /etc is a subdirectory of the / directory on the Unix "one big file > > system". > > > > > > Some file system must be mounted at /. > > > > > > Additional file systems must be mounted somewhere beneath /. Where > > they > > are mounted is call the "mountpoint". Mountpoints are > > traditionally > > subdirectories, and traditionally empty. When a file system is > > mounted > > there, the root of that file system is visible as the contents of > > the > > mountpoint. > > > > > > On my system, the virtual device /dev/mapper/sda4_crypt has a mount > > point of /. That file system contains a directory /etc. So, in > > the > > Unix "one big file system", the directories / and /etc both come > > from > > the file system on /dev/mapper/sda4_crypt. > > > > 2023-04-19 14:38:19 root@taz ~ > > # df / /etc > > Filesystem 1M-blocks Used Available Use% Mounted on > > /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / > > /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / > > > > > > AIUI you want the file system on the the partition /dev/nvme0n1p5 > > to be > > mounted at /tmp. The way to do that is to put the relevant entry > > back > > into /etc/fstab: > > > > UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2 > > > > And then reboot. > > > > > > > And, would there be anything wrong with, either way, running > > > update- > > > initramfs? > > > > > > Would that be run as: > > > > > > sudo update-initramfs -uv > > > > > > ? > > > > > > Unfortunately, more confusion -- there are two Linux "Initial > > ramdisk" > > solutions with very similar names -- initrd and initramfs. Forget > > about > > those for now. > > > > > > I would add the /etc entry back into /etc/fstab, reboot, run 'df / > > /etc', and see what happens. > > > Correction: > > add the /tmp entry back into /etc/fstab > > > > > > > > David > > > Okay . . . The problem seems to be solved! What I did: 1) Booted into Debian 11.6 Live/install usb thumb drive. 2) As root, mounted the / partition from the internal ssd. 3) On the internal ssd, replaced /etc/fstab with /etc/fstab.original. (On the internal ssd, I did not delete /tmp or its contents, and did not delete the tmp partition or its contents.) 4) Unmounted the / partition on the internal ssd. 5) Shutdown and removed the usb thumb drive. 6) Booted in to the computer as usual. It *seems* to have worked fine, with /tmp mounted on its dedicated partition again. But there may still be leftover stuff in /tmp, so maybe later I will again boot from the live usb, delete everything in /tmp (but not /tmp itself) on the internal ssd, and reboot into the system, which will presumably have re-populated with no leftovers. So far, so good. Much thanks to all who have weighed in on this!
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-20 03:00 +0200 |
| Subject | Re: [SOLVED] Re: /etc/fstab question (problem)? |
| Message-ID | <GmqOu-3bBO-5@gated-at.bofh.it> |
| In reply to | #257414 |
On 4/19/23 17:24, Default User wrote: >>>>>> On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote: >>>>>>> Perhaps update-initramfs is necessary after restoring of >>>>>>> /etc/fstab in any chosen approach. Looking at the Wikipedia page "Initial ramdisk": https://en.wikipedia.org/wiki/Initrd AIUI /tmp is mounted after the boot process is finished with the initial ramdisk. So, there is no need to run update-initramfs(8). > Okay . . . The problem seems to be solved! > > What I did: > > 1) Booted into Debian 11.6 Live/install usb thumb drive. > > 2) As root, mounted the / partition from the internal ssd. > > 3) On the internal ssd, replaced /etc/fstab with /etc/fstab.original. > (On the internal ssd, I did not delete /tmp or its contents, and did > not delete the tmp partition or its contents.) > > 4) Unmounted the / partition on the internal ssd. > > 5) Shutdown and removed the usb thumb drive. > > 6) Booted in to the computer as usual. > > It *seems* to have worked fine, with /tmp mounted on its dedicated > partition again. > > But there may still be leftover stuff in /tmp, so maybe later I will > again boot from the live usb, delete everything in /tmp (but not /tmp > itself) on the internal ssd, and reboot into the system, which will > presumably have re-populated with no leftovers. > > So far, so good. > > Much thanks to all who have weighed in on this! I am glad it worked out. :-) David
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-04-21 17:20 +0200 |
| Message-ID | <Gn0Ih-3xsG-3@gated-at.bofh.it> |
| In reply to | #257408 |
On 20/04/2023 04:03, David Christensen wrote: > * What if root attempts to remove everything under /etc, in anticipation > of mounting a file system at /etc, when one or more programs have one or > more open temporary files? David, you were wrote /etc instead of /tmp in several messages, so at certain moment I thought that original issue was due to attempt to really mount another partition to /etc (e.g. for easier backups). Later an entry for /tmp was added to fstab on mounted partition, perhaps new version of fstab even propagated to initramfs. However after reboot there was no an entry for /etc in the /etc/fstab file residing on the root partition, so init had no change to mount /etc with another fstab (with the entry for /etc). It is literally bootstrap problem. Fortunately Default User posted complete fstab, so it was possible to rule out such hypothesis. I used initramfs and initrd as synonyms because of file names /boot/initrd* and update-initramfs command. Even though /tmp entry should not be necessary during early init, I believe, it is safer to run "update-initrams -u" just to avoid surprise due to changes in fstab several days or weeks later when kernel update will arrive. It would be much harder to associate boot failure with fstab restored from backup instead of "broken" kernel package. I am glad to read that the issue is solved, I see no problem with using of live image (it is wise to always have it available). I think, in this case live image (unlike reboot) was not strictly necessary and may reduce down time if it is critical. I think, the following is safe enough (not verified, may contain typos or even errors): - backup /etc/fstab and current initrd - have a look into grub.cfg and grub manual to be able to boot using backup file - restore /etc/fstab from backup - Do not run "systemctl daemon-reload", since till shutdown systemd should work accordingly to content of old fstab version - update-initramfs -u - reboot. It is required after adding /tmp to fstab to make new fstab active and after update-initramfs to verify that new fstab does cause boot issue. Single reboot should be enough, however another one before update-initramfs is possible. - mount --bind / /mnt - remove files from /mnt/tmp/ remained from the previous boot. Otherwise some large file hidden by mounted /tmp may reduce free space available on the / partition - umount /mnt - remove initrd backup
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-22 00:50 +0200 |
| Message-ID | <Gn7JL-3Bw3-1@gated-at.bofh.it> |
| In reply to | #257466 |
On 4/21/23 08:12, Max Nikulin wrote: > On 20/04/2023 04:03, David Christensen wrote: >> * What if root attempts to remove everything under /etc, in >> anticipation of mounting a file system at /etc, when one or more >> programs have one or more open temporary files? > > David, you were wrote /etc instead of /tmp in several messages, I apologize for the errors. :-( I will strive to do more proofreading before posting. > I used initramfs and initrd as synonyms because of file names > /boot/initrd* and update-initramfs command. Even though /tmp entry > should not be necessary during early init, I believe, it is safer to run > "update-initrams -u" just to avoid surprise due to changes in fstab > several days or weeks later when kernel update will arrive. It would be > much harder to associate boot failure with fstab restored from backup > instead of "broken" kernel package. I am unaware of any single document that would allow us to definitively answer the question "what does initrd.img depend upon?". If anyone knows of such, please provide a citation. I find it strange that we run a tool named "update-initramfs" to update a file named "initrd.img-*". Should not the tool be named "update-initrd"? I would like to imagine that running update-initramfs(8) is always safe, but I seem to be running into a lot of WTF's on Linux and/or Debian again. > I am glad to read that the issue is solved, I see no problem with using > of live image (it is wise to always have it available). > > I think, in this case live image (unlike reboot) was not strictly > necessary and may reduce down time if it is critical. I think, the > following is safe enough (not verified, may contain typos or even errors): > - backup /etc/fstab and current initrd > - have a look into grub.cfg and grub manual to be able to boot using > backup file > - restore /etc/fstab from backup > - Do not run "systemctl daemon-reload", since till shutdown systemd > should work accordingly to content of old fstab version > - update-initramfs -u > - reboot. It is required after adding /tmp to fstab to make new fstab > active and after update-initramfs to verify that new fstab does cause > boot issue. Single reboot should be enough, however another one before > update-initramfs is possible. > - mount --bind / /mnt > - remove files from /mnt/tmp/ remained from the previous boot. Otherwise > some large file hidden by mounted /tmp may reduce free space available > on the / partition > - umount /mnt > - remove initrd backup As for the Linux initial ramdisk, and ignoring system configuration settings in memory: * The Linux initial ramdisk is a cache used by the boot process. If system configuration settings in a file on primary storage are created/ updated/ deleted, if initrd.img depends upon those settings, and if the initrd.img is not updated, then the system configuration settings exist in two places and those settings are out-of-sync [1,2]. When the system is rebooted, the resulting system configuration will be a mixture of settings from primary storage files and from initrd.img. * AIUI the BSD's do not have an initial ramdisk. If system configuration settings in a file on primary storage are created/ updated/ deleted, then the system configuration settings exist in only one place. When the system is rebooted, the resulting system configuration will be unambiguous. As for systemd: * AIUI systemd is a system management database comprised of text and binary files. systemd may hook into initrd.img. I assume systemd has a non-trivial schema with referential integrity requirements. The text files must have a syntax and the binary files must have a file structure. There must be an API to perform operations on all or part of the database. My interactions with systemd have been limited to running systemd CLI programs. If and when the systemd database and/or initrd.img components are damaged and/or out-of-sync such that boot fails, I have no idea how to fix that. * AIUI FreeBSD is configured via text files. I can edit them, check them into a version control system, run them through shell pipelines, etc.. If and when the system configuration is damaged such that boot fails, I know how to boot live media, mount filesystems, and work on those files. David [1] https://en.wikipedia.org/wiki/Don't_repeat_yourself [2] https://www.martinfowler.com/bliki/TwoHardThings.html
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-04-22 17:30 +0200 |
| Message-ID | <Gnnlv-3LtD-9@gated-at.bofh.it> |
| In reply to | #257471 |
On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote: > On 4/21/23 08:12, Max Nikulin wrote: > > On 20/04/2023 04:03, David Christensen wrote: > > > * What if root attempts to remove everything under /etc, in > > > anticipation of mounting a file system at /etc, when one or > > > more programs have one or more open temporary files? With one exception, I've not seen root (whichever process that refers to) doing anything like that in anticipation of mounting a filesystem, so I wondered where that realisation came from. The exception (which I haven't actually observed) is run-init tearing down the initramfs before the true root is mounted. > > I used initramfs and initrd as synonyms because of file names > > /boot/initrd* and update-initramfs command. Even though /tmp entry > > should not be necessary during early init, I believe, it is safer > > to run "update-initrams -u" just to avoid surprise due to changes > > in fstab several days or weeks later when kernel update will > > arrive. It would be much harder to associate boot failure with > > fstab restored from backup instead of "broken" kernel package. The OP obviously has a problem with /etc/fstab, in that they reported modifications having been made by an unknown agent. An important hint in determining what might have been responsible is to know the modification timestamp of the altered file, and whether any other files were modified within a short period bracketing that time. The OP's backup methods might not be up to that task if they're losing the metadata, but it's worth checking: the backups might also be stored elsewhere, with dates in their names, etc. AFAICT running update-initramfs has no effect as its /etc/fstab will remain empty. The booting kernel uses the root filesystem's fstab, located by the root= on the kernel command line. Upgrading the kernel will run update-initramfs, but not for any effect on the contained /etc/fstab. In fact, it's difficult to see any advantage in adding entries to the /etc/fstab in the initramfs. You would lose one of the important properties of the kernel/initrd pair which is that you can run it on a different machine with different root filesystems (selected by root=…) without having to modify them. (Cast your mind back to days of yore, when we had to run rdev to modify bytes at a certain kernel offset to change the root filesystem it would boot.) > I am unaware of any single document that would allow us to > definitively answer the question "what does initrd.img depend upon?". > If anyone knows of such, please provide a citation. /usr/sbin/mkinitramfs and the configuration parameters that it reads from /etc/initramfs/, I guess. (I assume you're not wanting to read about how the kernel turns compressed cpio archives into a cached filesystem.) > I find it strange that we run a tool named "update-initramfs" to > update a file named "initrd.img-*". Should not the tool be named > "update-initrd"? No, the initrd ought to be called initramfs. I think the changeover from ram disk to ram filesystem was during 2.6 kernel versions. I assume the name just stuck. > I would like to imagine that running update-initramfs(8) is always > safe, but I seem to be running into a lot of WTF's on Linux and/or > Debian again. It should always be safe, but be aware that initrds have got quite large nowadays, particularly with MODULES=most, so people with /boot on its own partition have to keep an eye on free space. > As for the Linux initial ramdisk, and ignoring system configuration > settings in memory: > > * The Linux initial ram[fs] is a cache used by the boot process. If > system configuration settings in a file on primary storage are > created/ updated/ deleted, if initrd.img depends upon those settings, > and if the initrd.img is not updated, then the system configuration > settings exist in two places and those settings are out-of-sync [1,2]. > When the system is rebooted, the resulting system configuration will > be a mixture of settings from primary storage files and from > initrd.img. That's why you see update-initramfs being run any time the relevant parts of the configuration change, avoiding that situation. > * AIUI the BSD's do not have an initial ramdisk. If system > configuration settings in a file on primary storage are created/ > updated/ deleted, then the system configuration settings exist in only > one place. When the system is rebooted, the resulting system > configuration will be unambiguous. Yes, I remember building custom kernels years ago, where you had to build in all the modules that might ever be necessary to find and mount the root filesystem. And all that code ran in kernel space. The benefit of an initramfs is that you don't need any filesystem drivers built into the kernel (you would need one were you to use a ram /disk/), and most of the code, which can be complex and extensive, runs in user space. Think decryption, RAID, networked file systems etc. > As for systemd: > > * AIUI systemd is a system management database comprised of text and > binary files. Is that right? I know systemd uses binary files for its logging (though it can and does write traditional text ones too). But can you point out some binary configuration files that systemd uses. > systemd may hook into initrd.img. Hmm, I got the impression that systemd, /sbin/init, PID1, started just as run-init finished tearing down all remnants of the initramfs, and mounted the real root filesystem. Looking for the string systemd in my own initrd.img, I have the binary: -rwxr-xr-x 1 678392 Apr 27 2020 main/usr/lib/systemd/systemd-udevd which looks like a slimmed down version of /bin/udevadm. It's difficult to imagine initramfs not containing udev. IDK whether non-systemd users have their own, special version of udev to avoid having a systemd hook into initrd.img. Then I see main/usr/lib/modprobe.d/systemd.conf containing two lines: options bonding max_bonds=0 options dummy numdummies=0 which is something to do with preventing bonding if/when some kernel module is loaded during the initramfs phase. Lastly, I see main/usr/lib/systemd/network/99-default.link containing: [Link] NamePolicy=keep kernel database onboard slot path MACAddressPolicy=persistent which is the backstop for udev's handling of network interfaces. > I assume systemd has > a non-trivial schema with referential integrity requirements. The > text files must have a syntax and the binary files must have a file > structure. There must be an API to perform operations on all or part > of the database. Sorry, which operations on what database? > My interactions with systemd have been limited to > running systemd CLI programs. If and when the systemd database and/or > initrd.img components are damaged and/or out-of-sync such that boot > fails, I have no idea how to fix that. Sorry, you've lost me; I thought it was the kernel that booted a linux system, not systemd. > * AIUI FreeBSD is configured via text files. I can edit them, check > them into a version control system, run them through shell pipelines, > etc.. If and when the system configuration is damaged such that boot > fails, I know how to boot live media, mount filesystems, and work on > those files. Funny—that's rather like what we sysadmins do on linux, apart from being rather vague when compared with the specific details we are dissecting here. > [1] https://en.wikipedia.org/wiki/Don't_repeat_yourself When an ocean liner leaves port, it doesn't use its main engines: tugs tow it out of the harbour using their engines. The ship's master wouldn't be able to navigate the liner into the main channel, but a pilot handles that with ease, before disappearing over the side into a pilot boat. Once at sea, the liner needs neither tugs nor pilot. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-23 04:00 +0200 |
| Message-ID | <Gnxbb-3Rw1-3@gated-at.bofh.it> |
| In reply to | #257476 |
On 4/22/23 08:24, David Wright wrote: > On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote: >> On 4/21/23 08:12, Max Nikulin wrote: >>> On 20/04/2023 04:03, David Christensen wrote: >>>> * What if root attempts to remove everything under /etc, in >>>> anticipation of mounting a file system at /etc, when one or >>>> more programs have one or more open temporary files? > > With one exception, I've not seen root (whichever process that > refers to) doing anything like that in anticipation of mounting > a filesystem, so I wondered where that realisation came from. > The exception (which I haven't actually observed) is run-init > tearing down the initramfs before the true root is mounted. You're right; what I wrote makes no sense -- because it is wrong: On 4/21/23 08:12, Max Nikulin wrote: > David, you were wrote /etc instead of /tmp in several messages On 4/21/23 15:46, David Christensen wrote: > I apologize for the errors. :-( <snip> "Back in the day", people running Linux had computers with limited amounts of storage and memory. I imagine an initial ramdisk seemed like an good trade-off/ work-around at that time. But today, this is my Linux daily driver: 2023-04-22 16:25:50 root@taz ~ # cat /etc/debian_version ; uname -a 11.6 Linux taz 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux 2023-04-22 17:52:29 root@taz ~ # lsmem RANGE SIZE STATE REMOVABLE BLOCK 0x0000000000000000-0x000000007fffffff 2G online yes 0-15 0x0000000100000000-0x000000087fffffff 30G online yes 32-271 Memory block size: 128M Total online memory: 32G Total offline memory: 0B 2023-04-22 18:40:09 root@taz ~ # df /boot Filesystem 1M-blocks Used Available Use% Mounted on /dev/sda2 921M 114M 744M 14% /boot 2023-04-22 16:26:05 root@taz ~ # ls -l /boot/initrd.img-5.10.0-21-amd64 /boot/vmlinuz-5.10.0-21-amd64 -rw-r--r-- 1 root root 47837534 Mar 18 19:23 /boot/initrd.img-5.10.0-21-amd64 -rw-r--r-- 1 root root 7019136 Jan 21 06:35 /boot/vmlinuz-5.10.0-21-amd64 The Linux kernel is ~7 MB and initrd.img is ~48 MB. My daily driver is complete overkill. Even my 2007 laptop has 2 GB of memory an a 1 GB boot partition/ filesystem. Still overkill. I would gladly accept a 48 MB vmlinuz to be rid of initrd.img and its complexities. The resource hogs today are the apps, not the OS. Give me a KISS OS. David
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-04-23 06:20 +0200 |
| Message-ID | <GnzmF-3T7A-1@gated-at.bofh.it> |
| In reply to | #257496 |
On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote: > On 4/22/23 08:24, David Wright wrote: > > On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote: > > > On 4/21/23 08:12, Max Nikulin wrote: > > > > On 20/04/2023 04:03, David Christensen wrote: > > > > > * What if root attempts to remove everything under /etc, in > > > > > anticipation of mounting a file system at /etc, when one or > > > > > more programs have one or more open temporary files? > > > > With one exception, I've not seen root (whichever process that > > refers to) doing anything like that in anticipation of mounting > > a filesystem, so I wondered where that realisation came from. > > The exception (which I haven't actually observed) is run-init > > tearing down the initramfs before the true root is mounted. > > > You're right; what I wrote makes no sense -- because it is wrong: > > On 4/21/23 08:12, Max Nikulin wrote: > > David, you were wrote /etc instead of /tmp in several messages > > On 4/21/23 15:46, David Christensen wrote: > > I apologize for the errors. :-( I had seen your correction, but my point wasn't dependent on any particular choice of directory, but with mounting filesystems in general—onto any mountpoint. > "Back in the day", people running Linux had computers with limited > amounts of storage and memory. I imagine an initial ramdisk seemed > like an good trade-off/ work-around at that time. > > But today, this is my Linux daily driver: > Total online memory: 32G That must be nice. I don't know what it might have cost. I'm afraid I only use cast-offs. The oldest has ½GB memory. > # ls -l /boot/initrd.img-5.10.0-21-amd64 /boot/vmlinuz-5.10.0-21-amd64 > -rw-r--r-- 1 root root 47837534 Mar 18 19:23 > /boot/initrd.img-5.10.0-21-amd64 > -rw-r--r-- 1 root root 7019136 Jan 21 06:35 /boot/vmlinuz-5.10.0-21-amd64 > The Linux kernel is ~7 MB and initrd.img is ~48 MB. My daily driver > is complete overkill. I think your kernel is probably more like 12.3MB of code. Your initrd is larger than mine: I'd have to see inside to tell why, but no matter. > Even my 2007 laptop has 2 GB of memory an a 1 GB boot partition/ > filesystem. Still overkill. Overkill for what? I don't understand. > I would gladly accept a 48 MB vmlinuz to be rid of initrd.img and its > complexities. > > The resource hogs today are the apps, not the OS. Give me a KISS OS. I can't understand why one would want to load all that kernel code just to not use it. OK, for some reason you find the initrd complex. (I don't any details about how freeBSD boots up as I haven't used it.) I know you not interested in how it works or what it's for. I don't see any sign that you've had difficulties in setting it up; it's just there. It gets generated by the installer, and updated at various times, like kernel upgrades. So what are you here for? To tell us you're confused? To debate its name? To campaign for its abolition? To throw mud? To say WTF to yourself again? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-23 10:20 +0200 |
| Message-ID | <GnD6W-3VrB-13@gated-at.bofh.it> |
| In reply to | #257498 |
On 4/22/23 21:11, David Wright wrote: > On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote: >> On 4/22/23 08:24, David Wright wrote: >>> On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote: >>>> On 4/21/23 08:12, Max Nikulin wrote: >>>>> On 20/04/2023 04:03, David Christensen wrote: >>>>>> * What if root attempts to remove everything under /etc, in >>>>>> anticipation of mounting a file system at /etc, when one or >>>>>> more programs have one or more open temporary files? >>> >>> With one exception, I've not seen root (whichever process that >>> refers to) doing anything like that in anticipation of mounting >>> a filesystem, so I wondered where that realisation came from. >>> The exception (which I haven't actually observed) is run-init >>> tearing down the initramfs before the true root is mounted. >> >> >> You're right; what I wrote makes no sense -- because it is wrong: >> >> On 4/21/23 08:12, Max Nikulin wrote: >>> David, you were wrote /etc instead of /tmp in several messages >> >> On 4/21/23 15:46, David Christensen wrote: >>> I apologize for the errors. :-( > > I had seen your correction, but my point wasn't dependent on any > particular choice of directory, but with mounting filesystems > in general—onto any mountpoint. AIUI open(2) returns a file handle that a process uses to access file contents. If a second file system is mounted such that it overlays the file path while the file is still open, the process can still make system calls using the file descriptor (read(2), write(2), lseek(2), close(2)). But if the process makes system calls using the file path (notably unlink(2)), there are several possibilities: 1. The process may not have authority to access that path. 2. The path may not exist. 3. The process may find an old file, directory, or something at that path. 4. The process may find a new and in-use something at that path which belongs to another process. My conclusion was that the safest approach would be for the OP to restore the fstab(5) entry for /tmp and reboot. This keeps file descriptors and file paths consistent -- both during shutdown and during the next start-up (including the case where mounting the second file system fails). > >> "Back in the day", people running Linux had computers with limited >> amounts of storage and memory. I imagine an initial ramdisk seemed >> like an good trade-off/ work-around at that time. >> >> But today, this is my Linux daily driver: > >> Total online memory: 32G > > That must be nice. I don't know what it might have cost. I'm afraid > I only use cast-offs. The oldest has ½GB memory. https://www.ebay.com/itm/393918586141 > >> # ls -l /boot/initrd.img-5.10.0-21-amd64 /boot/vmlinuz-5.10.0-21-amd64 >> -rw-r--r-- 1 root root 47837534 Mar 18 19:23 >> /boot/initrd.img-5.10.0-21-amd64 >> -rw-r--r-- 1 root root 7019136 Jan 21 06:35 /boot/vmlinuz-5.10.0-21-amd64 > >> The Linux kernel is ~7 MB and initrd.img is ~48 MB. My daily driver >> is complete overkill. > > I think your kernel is probably more like 12.3MB of code. Where do you get 12.3MB? > Your initrd > is larger than mine: I'd have to see inside to tell why, but no matter. > >> Even my 2007 laptop has 2 GB of memory an a 1 GB boot partition/ >> filesystem. Still overkill. > > Overkill for what? I don't understand. 2 GB of memory and 1 GB of boot file system are more than enough to boot Linux or FreeBSD. <snip> David
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2023-04-24 18:30 +0200 |
| Message-ID | <Go7eF-4dY8-5@gated-at.bofh.it> |
| In reply to | #257500 |
On Sun, 23 Apr 2023 01:14:05 -0700 David Christensen <dpchrist@holgerdanske.com> wrote: > On 4/22/23 21:11, David Wright wrote: > > On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote: ... > >> "Back in the day", people running Linux had computers with limited > >> amounts of storage and memory. I imagine an initial ramdisk seemed > >> like an good trade-off/ work-around at that time. > >> > >> But today, this is my Linux daily driver: > > > >> Total online memory: 32G > > > > That must be nice. I don't know what it might have cost. I'm afraid > > I only use cast-offs. The oldest has ½GB memory. > > > https://www.ebay.com/itm/393918586141 I have something similar - an HP Z440 with 32GB of RAM. It's not quite as "modern" as the Precision at that link, but it can currently be readily found for as little as $250 USD (doubtless less if one scrounges around): https://www.ebay.com/itm/225546840287 -- Celejar
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-04-25 15:00 +0200 |
| Message-ID | <GoqqZ-4qfB-5@gated-at.bofh.it> |
| In reply to | #257500 |
On Sun 23 Apr 2023 at 01:14:05 (-0700), David Christensen wrote: > On 4/22/23 21:11, David Wright wrote: > > On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote: > > > "Back in the day", people running Linux had computers with limited > > > amounts of storage and memory. I imagine an initial ramdisk seemed > > > like an good trade-off/ work-around at that time. > > > > > > But today, this is my Linux daily driver: > > > > > Total online memory: 32G > > > > That must be nice. I don't know what it might have cost. I'm afraid > > I only use cast-offs. The oldest has ½GB memory. > > https://www.ebay.com/itm/393918586141 When the boat comes in, maybe. The most expensive piece of computing equipment I've bought is my first 500GB internal PATA disk, which was £120 in 2007. It still runs. > > > # ls -l /boot/initrd.img-5.10.0-21-amd64 /boot/vmlinuz-5.10.0-21-amd64 > > > -rw-r--r-- 1 root root 47837534 Mar 18 19:23 > > > /boot/initrd.img-5.10.0-21-amd64 > > > -rw-r--r-- 1 root root 7019136 Jan 21 06:35 /boot/vmlinuz-5.10.0-21-amd64 > > > > > The Linux kernel is ~7 MB and initrd.img is ~48 MB. My daily driver > > > is complete overkill. > > > > I think your kernel is probably more like 12.3MB of code. > > Where do you get 12.3MB? $ sudo dmesg | grep -e 'kernel code' -e 'Freeing' [ 0.073101] Memory: 261408K/2087060K available (12295K kernel code, 2537K rwdata, 7560K rodata, 2660K init, 5468K bss, 85560K reserved, 0K cma-reserved) [ 0.216704] Freeing SMP alternatives memory: 32K [ 1.301737] Freeing initrd memory: 11472K [ 1.417122] Freeing unused decrypted memory: 2036K [ 1.418881] Freeing unused kernel image (initmem) memory: 2660K [ 1.436299] Freeing unused kernel image (text/rodata gap) memory: 2040K [ 1.436768] Freeing unused kernel image (rodata/data gap) memory: 632K $ uname -vsor Linux 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) GNU/Linux $ I take it you're not running an i386: $ sudo dmesg | grep -e 'kernel code' -e 'Freeing' [ 0.067626] Memory: 472644K/522744K available (8213K kernel code, 1158K rwdata, 2516K rodata, 872K init, 476K bss, 50100K reserved, 0K cma-reserved, 0K highmem) [ 0.126156] Freeing SMP alternatives memory: 32K [ 2.906178] Freeing initrd memory: 30656K [ 3.694974] Freeing unused kernel image (initmem) memory: 872K $ uname -vsor Linux 5.10.0-21-686 #1 SMP Debian 5.10.162-1 (2023-01-21) GNU/Linux $ > > Your initrd > > is larger than mine: I'd have to see inside to tell why, but no matter. > > > > > Even my 2007 laptop has 2 GB of memory an a 1 GB boot partition/ > > > filesystem. Still overkill. > > > > Overkill for what? I don't understand. > > 2 GB of memory and 1 GB of boot file system are more than enough to > boot Linux or FreeBSD. That looks like a restatement, so in order to understand /why/ you might say that, I have to put words into your mouth; sorry if they're the wrong ones. You seem to be saying that because 2GB/1GB is enough to boot a system, then that's a good reason to allow the running kernel to be 48+12=60MB in size, just to eliminate the initramfs. And the sole reason for wishing to eliminate it is because of its "complexity", as you see it. I don't buy that, and I don't think most linux users want their kernel stuffed with 80% of code that's never used and is only there for other people who might some day boot their kernel on a system that has a fancy way of accessing the root filesystem that doesn't interest them, and I, for one, would never be able to afford. And that's before you look at the advantages of developing and running that 80% of the code in user-mode rather than kernel-mode, in terms of debugging, security, etc. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-23 17:20 +0200 |
| Subject | old memory sticks (was Re: /etc/fstab question (problem)? |
| Message-ID | <GnJFn-3Zrb-1@gated-at.bofh.it> |
| In reply to | #257498 |
David Wright wrote:
...
> That must be nice. I don't know what it might have cost. I'm afraid
> I only use cast-offs. The oldest has ½GB memory.
i have some older memory sticks and chips that i will gladly
send to anyone who has older machines. the only condition i
would have for the gift is to pass them on to anyone else who
might need them as i'm not going to "part out" the list to one
item at a time. so you get the whole small pile of sticks/chips.
first come, first served. send me an e-mail (to this address)
with your mailing address.
let me see what i have (i'm in need of a distraction this
morning so here's the list as best i can see them - i'm not
a PC or memory guru so i don't know exactly what these are
now as it has been quite some time since i pulled them and
aside from what is right on the chips all i can say is that
they were working when i pulled them):
(pins not as well plated with gold)
2 pcs - IC side markings HYUNDAI KOREA, 8 IC's,
(markings on IC HY5117400A J-70 9629A KOREA)
- 1 other side markings ST-102A HYM532410AM-70 6H82AA
- 2 other side markings ST-103 HYM532410AM-70 6H82AA
- 72 pins if the numbers next to the pins are right
(these ones are heavier and have a nice layer of gold
on the pins compared to the ones above i'd say they
are works of art)
2 pcs - IC side markings MADE IN JAPAN, 8 IC's
both marked QQ18UU 94-VO HB56A13 2BV-7B 9419
- other side marking on both was SAN-TM94VO
one marked AD, other marked BB
- 72 pins
2 pcs - came from a COMPAC pc, 8 IC's on one side
(the B might be an 8)
both marked MTBLSDT864AG-10EC7 PC100-222-620,
one says 64MB, SYNCH, 100MHz, CL2 other doesn't
both have part number sticker and other numbers
on them - i'm not putting them on here...
- 84 pins
1 pc - 8 IC's on each side, very thin,
printed on tag:
MT1GLSTDT464AG-10BC4 9829 DA ST 617054 PC100-323-620
the printing is very light on the ICs, i can barely see
them (as best i can make it out)
9828 C USA MT 48LC2M8A1 TG -8B S
- 84 pins
1 pc - 8 IC's total more pins than 84 (i ain't counting them)
INFINEON
printed on tag:
HYS64D32300HU-5-C C3E53318
Assembled in Malaysia
256MB, DDR, 400, CL3 PC3200U-30330-A0
songbird
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-24 03:50 +0200 |
| Subject | [SOLVED]: old memory sticks |
| Message-ID | <GnTv3-45bF-3@gated-at.bofh.it> |
| In reply to | #257504 |
songbird wrote: ... all set thanks for the reply. songbird
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-20 15:10 +0200 |
| Message-ID | <GmCcW-3iLz-3@gated-at.bofh.it> |
| In reply to | #257400 |
Default User wrote: ... > Well, now I am totally confused. > > I had hoped for, and really expected, an easy, obvious, intuitive > solution. But I guess that may be a distant memory of the good old > days, before [insert string of four-letter words here] like dbus, > systemd, and Gnome 3. And when partitions were named /dev/hda5, not > 6a105a72-f5d5-441b-b926-1e405151ee84. > > Sigh. ... i use labels on all of my partitions and give them a legible name. those are what i use in my fstab and also in any grub or refind configs. i hate UUIDS. i do understand what they're for and know about them, but i do not need them for the simple stuff i'm doing. songbird
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-04-20 17:20 +0200 |
| Message-ID | <GmEeK-3jV5-5@gated-at.bofh.it> |
| In reply to | #257428 |
On 20/04/2023 19:05, songbird wrote: > Default User wrote: >> And when partitions were named /dev/hda5, not >> 6a105a72-f5d5-441b-b926-1e405151ee84. > > i use labels on all of my partitions and give them a > legible name. those are what i use in my fstab and also > in any grub or refind configs. > > i hate UUIDS. i do understand what they're for and know > about them, but i do not need them for the simple stuff i'm > doing. Since Default User is playing with restoring partitions from backup and cloning disks lies somewhere nearby, it may happen that 2 disks with identical partition labels may be installed simultaneously. Partition UUIDs are affected as well, but e.g. sgdisk has a dedicated option: https://www.rodsbooks.com/gdisk/sgdisk.html > -G, --randomize-guids > Randomize the disk's GUID and all partitions' unique GUIDs (but not > their partition type code GUIDs). This function may be used after > cloning a disk in order to render all GUIDs once again unique P.S. Some people hate consistent network device naming that was introduced to solve the same problem with eth0-like names as the one caused widespread of UUID in fstab instead of /dev/hdaX.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-04-21 06:30 +0200 |
| Message-ID | <GmQzf-3rnk-3@gated-at.bofh.it> |
| In reply to | #257439 |
On Thu 20 Apr 2023 at 22:16:56 (+0700), Max Nikulin wrote: > On 20/04/2023 19:05, songbird wrote: > > Default User wrote: > > > And when partitions were named /dev/hda5, not > > > 6a105a72-f5d5-441b-b926-1e405151ee84. With modern hardware, you'd probably not want to go back to those device names, because the way the buses work, the internal drives can be assigned different names according to what's plugged into the computer. > > i use labels on all of my partitions and give them a > > legible name. those are what i use in my fstab and also > > in any grub or refind configs. > > > > i hate UUIDS. i do understand what they're for and know > > about them, but i do not need them for the simple stuff i'm > > doing. > > Since Default User is playing with restoring partitions from backup > and cloning disks lies somewhere nearby, it may happen that 2 disks > with identical partition labels may be installed simultaneously. > > Partition UUIDs are affected as well, Precisely, and users with a small collection of disks are far more likely to anticipate and rectify a LABEL collision than a UUID one. Humans prefer working with names and small numbers rather than 128-bit numbers. It takes little effort to devise a satisfactory naming scheme. > but e.g. sgdisk has a dedicated > option: > https://www.rodsbooks.com/gdisk/sgdisk.html > > -G, --randomize-guids > > Randomize the disk's GUID and all partitions' unique GUIDs (but not > > their partition type code GUIDs). This function may be used after > > cloning a disk in order to render all GUIDs once again unique Very useful for the sysadmin who has a way of keeping track of the filesystem and partition UUIDS on each disk; the point being that UUIDs scale well, particularly when handled by software. Repurposing a well-known meme¹: UUIDs are for people who treat their disks like cattle, LABELs are for those who treat them like pets. Were I using UUIDs for unlocking and mounting disks at the command line, or in files like fstab, the giveaway is that I would have to depend on the machine to tell me what the UUIDs were, either by completion, or by copy/paste. Seriously, no one ever types a UUID into a computer, do they? > P.S. Some people hate consistent network device naming that was > introduced to solve the same problem with eth0-like names as the one > caused widespread of UUID in fstab instead of /dev/hdaX. That's not the same problem at all. Network device names aren't, and don't need to be, unique across even just two machines. What they need to be is stable and persistent on each individual machine. Typically, the people who dislike them seem to be those who have no necessity for them, often because their machines contain but a single device. It seems simple to configure any device names you like, so I don't really understand why they complain. ¹ originally applied to servers, I believe. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-04-21 06:50 +0200 |
| Message-ID | <GmQSB-3rtv-1@gated-at.bofh.it> |
| In reply to | #257455 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Apr 20, 2023 at 11:29:26PM -0500, David Wright wrote: > On Thu 20 Apr 2023 at 22:16:56 (+0700), Max Nikulin wrote: > > On 20/04/2023 19:05, songbird wrote: > > > Default User wrote: > > > > And when partitions were named /dev/hda5, not > > > > 6a105a72-f5d5-441b-b926-1e405151ee84. > > With modern hardware, you'd probably not want to go back to those > device names, because the way the buses work, the internal drives > can be assigned different names according to what's plugged into > the computer. FWIW, I do live with that (laptop here, one spinning rust inside). The built-in disk is sda, when I stuff a usb stick in, it'll become sdb unless... I stuff the usb stick too early in the boot process :) I know this and can cope with it pretty well. But that's what labels or (ugh) UUIDs were designed to solve. There's a sweet spot between how much the user should "know" and how much the system solves implicitly. Where this exactly is depends on many factors, and it isn't the same for everyone. Sometimes I doubt we are doing us a favour by making systems "smarter" and users dumber: we create more and more dependencies. But hey, that's me. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Default User <hunguponcontent@gmail.com> |
|---|---|
| Date | 2023-04-20 16:30 +0200 |
| Message-ID | <GmDsl-3jpR-7@gated-at.bofh.it> |
| In reply to | #257400 |
On Thu, 2023-04-20 at 10:09 +0200, DdB wrote: > You got your plan mapped out. and i agree, except for one little > detail: > see below. - > > Am 19.04.2023 um 22:06 schrieb Default User: > > > I think, it is the case when reboot is safer. Open file > > > descriptors > > > remain on the original partition. However I do not expect that > > > single > > > user mode or booting from live image is required. Just restore > > > original > > > /etc/fstab and reboot. > > > > > > Perhaps update-initramfs is necessary after restoring of > > > /etc/fstab > > > in > > > any chosen approach. > > > > > > > > > > > > Well, now I am totally confused. > > > > I had hoped for, and really expected, an easy, obvious, intuitive > > solution. But I guess that may be a distant memory of the good old > > days, before [insert string of four-letter words here] like dbus, > > systemd, and Gnome 3. And when partitions were named /dev/hda5, not > > 6a105a72-f5d5-441b-b926-1e405151ee84. > > > > Sigh. > > > > Anyway, here is where I am at: > > > > I have two Clonezilla backups. > > 1) a full disk backup. > > 2) a "partitions" backup. > > So, if things really go bad, I can theoretically revert to the > > setup as > > of 2023-04-18, when this thread was started. > > > > I also have a backup of the current /tmp directory (from under the > > / > > directory). > > And I have a backup of the old tmp partition. > > > > Both of these tmp backups were made using a Debian Stable 11.6 > > Live/install usb thumb drive, as root user. > > > > All of these backups are on an external usb hdd. > > > > Here is what was in the (root) tmp directory: > > > > _root_partition/tmp > > total 32K > > 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./ > > 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../ > > 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/ > > 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/ > > 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/ > > 88473610 drwx------ 2 [user] [user] 4.0K Apr 19 14:18 tracker- > > extract- > > files.116/ > > 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/ > > 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/ > > > > And here is what was in the old tmp partition: > > > > total 48K > > 88473611 drwxr-xr-t 10 root root 4.0K Apr 19 14:20 ./ > > 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ > > 88473618 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .font- > > unix/ > > 88473615 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .ICE-unix/ > > 88473620 drwx------ 2 root root 4.0K Apr 19 14:20 > > lost+found/ > > 88473619 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .Test- > > unix/ > > 88473624 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > > extract-files.1000/ > > 88473623 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > > extract-files.116/ > > 88473621 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1024- > > lock > > 88473622 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1025- > > lock > > 88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .X11-unix/ > > 88473617 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .XIM-unix/ > > > > As far as I can tell, there is nothing crucial in either tmp > > backup. > > > > BTW, I know nothing about bind or mount --bind. I looked them up > > briefly, and decided that they are too difficult and maybe > > dangerous to > > try to learn and use under the current circumstances. > > > > So here is what I am thinking of doing: > > > > While running from within the Debian Stable 11.6 Live/install usb > > thumb > > drive, as root user: > > > > 1) On the computer's internal ssd, delete the /tmp directory and > > its > > contents. > Do NOT delete the directory itself, only its content, as it will be > used > as the mountpoint for your /tmp drive. > > > > > 2) On the computer's internal ssd, delete the contents of the old > > tmp > > partition, but not the partition itself. > > > > 3) On the computer's internal ssd, replace /etc/fstab with > > /etc/fstab.original, renaming it /etc/fstab. I have already made a > > copy > > of the current /etc/fstab as /etc/fstab.as-of-2023-04-19. > > > > The UUIDs of all partitions on computer's internal ssd seem to be > > the > > same as in /etc/fstab.original. > > > > (Note: in /etc/fstab.original, it states "Please run 'systemctl > > daemon- > > reload' after making changes here." Since I am doing all this from > > a > > live usb, I do not think that applies, so I would skip that.) > > > > Then I would shut down, remove the usb thumb drive, and boot into > > the > > Debian system on the computer's internal ssd. > > > > I hope that from then on, the system would mount the old tmp > > partition > > on the computer's internal ssd as /tmp, re-populating it > > automatically, > > and use it as such from then on. > > > > Does that seem reasonable? > > > > Or am I missing something, obvious or not. > > Please report your success, will you? > Actually, I did not end up having to delete anything. From within the live usb, essentially I just replaced by copying /etc/fstab with /etc/fstab.original, and the rebooted. I did seem to work, but just to be thorough, I again booted into the live usb and deleted the contents of /tmp, which was of course by then on the dedicated tmp partition, and then rebooted again into the system. Okay so far, but note that my system is relatively simple, without anything complex or exotic. Users with more complicated setups might experience less favorable results.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-04-19 22:40 +0200 |
| Message-ID | <GmmKR-39dH-3@gated-at.bofh.it> |
| In reply to | #257395 |
On Wed 19 Apr 2023 at 18:07:51 (+0700), Max Nikulin wrote: > On 19/04/2023 16:16, David Christensen wrote: > > On 4/18/23 20:16, Stefan Monnier wrote: > > > > > You can also do > > > > > > mount --bind / /mnt > > > > > > and then look at /mnt/tmp. > > > No need to reboot into single-user mode for that. Yes, whichever method you're most comfortable with. Not using bind mounts for anything that they're required for, I find them "complicated". > > +1 I like that better than the reboot/ live drive idea I posted. > > I think, it is the case when reboot is safer. Open file descriptors > remain on the original partition. However I do not expect that single > user mode or booting from live image is required. Just restore > original /etc/fstab and reboot. I was merely posting the results of a thought experiment. In reality, I can just cleanup /tmp on one root filesystem whenever I happen to have booted into the other system on the same disk (which always exists). But the point of my post was that past evidence from this list shows that people have run systems with significant disk usage hidden from them by being mounted over, and all because they didn't think to look. > Perhaps update-initramfs is necessary after restoring of /etc/fstab in > any chosen approach. I've never seen /etc/fstab other than empty inside an initrd. Maybe it's init-scheme dependent, IDK. Cheers, David.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web